Author: Aubrey Li <[email protected]> Date: Sun Jan 26 10:22:50 2025 +0800 ACPI: PRM: Remove unnecessary strict handler address checks commit 7f5704b6a143b8eca640cba820968e798d065e91 upstream. Commit 088984c8d54c ("ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context") added unnecessary strict handler address checks, causing the PRM module to fail in translating memory error addresses. Both static data buffer address and ACPI parameter buffer address may be NULL if they are not needed, as described in section 4.1.2 PRM Handler Information Structure of Platform Runtime Mechanism specification [1]. Here are two examples from real hardware: ----PRMT.dsl---- - staic data address is not used [10Ch 0268 2] Revision : 0000 [10Eh 0270 2] Length : 002C [110h 0272 16] Handler GUID : F6A58D47-E04F-4F5A-86B8-2A50D4AA109B [120h 0288 8] Handler address : 0000000065CE51F4 [128h 0296 8] Satic Data Address : 0000000000000000 [130h 0304 8] ACPI Parameter Address : 000000006522A718 - ACPI parameter address is not used [1B0h 0432 2] Revision : 0000 [1B2h 0434 2] Length : 002C [1B4h 0436 16] Handler GUID : 657E8AE6-A8FC-4877-BB28-42E7DE1899A5 [1C4h 0452 8] Handler address : 0000000065C567C8 [1CCh 0460 8] Satic Data Address : 000000006113FB98 [1D4h 0468 8] ACPI Parameter Address : 0000000000000000 Fixes: 088984c8d54c ("ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context") Reported-and-tested-by: Shi Liu <[email protected]> Cc: All applicable <[email protected]> Signed-off-by: Aubrey Li <[email protected]> Link: https://uefi.org/sites/default/files/resources/Platform%20Runtime%20Mechanism%20-%20with%20legal%20notice.pdf # [1] Reviewed-by: Koba Ko <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: Minor changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Andy Shevchenko <[email protected]> Date: Mon Feb 3 21:46:29 2025 +0200 ACPI: property: Fix return value for nval == 0 in acpi_data_prop_read() [ Upstream commit ab930483eca9f3e816c35824b5868599af0c61d7 ] While analysing code for software and OF node for the corner case when caller asks to read zero items in the supposed to be an array of values I found that ACPI behaves differently to what OF does, i.e. 1. It returns -EINVAL when caller asks to read zero items from integer array, while OF returns 0, if no other errors happened. 2. It returns -EINVAL when caller asks to read zero items from string array, while OF returns -ENODATA, if no other errors happened. Amend ACPI implementation to follow what OF does. Fixes: b31384fa5de3 ("Driver core: Unified device properties interface for platform firmware") Signed-off-by: Andy Shevchenko <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: Added empty line after a conditional ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Edson Juliano Drosdeck <[email protected]> Date: Tue Jan 14 14:06:19 2025 -0300 ALSA: hda/realtek: Enable headset mic on Positivo C6400 commit 1aec3ed2e3e1512aba15e7e790196a44efd5f0a7 upstream. Positivo C6400 is equipped with ALC269VB, and it needs ALC269VB_FIXUP_ASUS_ZENBOOK quirk to make its headset mic work. Also must to limits the microphone boost. Signed-off-by: Edson Juliano Drosdeck <[email protected]> Cc: <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sebastian Wiese-Wagner <[email protected]> Date: Mon Jan 20 19:12:40 2025 +0100 ALSA: hda/realtek: Enable Mute LED on HP Laptop 14s-fq1xxx commit 711aad3c43a9853657e00225466d204e46ae528b upstream. This HP Laptop uses ALC236 codec with COEF 0x07 controlling the mute LED. Enable existing quirk for this device. Signed-off-by: Sebastian Wiese-Wagner <[email protected]> Cc: <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kuan-Wei Chiu <[email protected]> Date: Wed Jan 29 00:54:15 2025 +0800 ALSA: hda: Fix headset detection failure due to unstable sort commit 3b4309546b48fc167aa615a2d881a09c0a97971f upstream. The auto_parser assumed sort() was stable, but the kernel's sort() uses heapsort, which has never been stable. After commit 0e02ca29a563 ("lib/sort: optimize heapsort with double-pop variation"), the order of equal elements changed, causing the headset to fail to work. Fix the issue by recording the original order of elements before sorting and using it as a tiebreaker for equal elements in the comparison function. Fixes: b9030a005d58 ("ALSA: hda - Use standard sort function in hda_auto_parser.c") Reported-by: Austrum <[email protected]> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219158 Tested-by: Austrum <[email protected]> Cc: [email protected] Signed-off-by: Kuan-Wei Chiu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Borislav Petkov <[email protected]> Date: Mon Jan 13 13:52:24 2025 +0100 APEI: GHES: Have GHES honor the panic= setting [ Upstream commit 5c0e00a391dd0099fe95991bb2f962848d851916 ] The GHES driver overrides the panic= setting by force-rebooting the system after a fatal hw error has been reported. The intent being that such an error would be reported earlier. However, this is not optimal when a hard-to-debug issue requires long time to reproduce and when that happens, the box will get rebooted after 30 seconds and thus destroy the whole hw context of when the error happened. So rip out the default GHES panic timeout and honor the global one. In the panic disabled (panic=0) case, the error will still be logged to dmesg for later inspection and if panic after a hw error is really required, then that can be controlled the usual way - use panic= on the cmdline or set it in the kernel .config's CONFIG_PANIC_TIMEOUT. Reported-by: Feng Tang <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Feng Tang <[email protected]> Reviewed-by: Ira Weiny <[email protected]> Link: https://patch.msgid.link/20250113125224.GFZ4UMiNtWIJvgpveU@fat_crate.local Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Anshuman Khandual <[email protected]> Date: Mon Dec 2 12:14:07 2024 +0530 arm64/mm: Ensure adequate HUGE_MAX_HSTATE [ Upstream commit 1e5823c8e86de83a43d59a522b4de29066d3b306 ] This asserts that HUGE_MAX_HSTATE is sufficient enough preventing potential hugetlb_max_hstate runtime overflow in hugetlb_add_hstate() thus triggering a BUG_ON() there after. Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Ryan Roberts <[email protected]> Cc: Mark Rutland <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Anshuman Khandual <[email protected]> Reviewed-by: Ryan Roberts <[email protected]> Reviewed-by: Gavin Shan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Dec 13 15:54:12 2024 +0100 arm64: dts: qcom: sm6115: Fix ADSP memory base and length commit 47d178caac3ec13f5f472afda25fcfdfaa00d0da upstream. The address space in ADSP PAS (Peripheral Authentication Service) remoteproc node should point to the QDSP PUB address space (QDSP6...SS_PUB): 0x0a40_0000 with length of 0x4040. 0x0ab0_0000, value used so far, is the SSC_QUPV3 block, so entierly unrelated. Correct the base address and length, which should have no functional impact on Linux users, because PAS loader does not use this address space at all. Cc: [email protected] Fixes: 96ce9227fdbc ("arm64: dts: qcom: sm6115: Add remoteproc nodes") Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-23-2e0036fccd8d@linaro.org Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Dec 13 15:54:11 2024 +0100 arm64: dts: qcom: sm6115: Fix CDSP memory length commit 846f49c3f01680f4af3043bf5b7abc9cf71bb42d upstream. The address space in MPSS/Modem PAS (Peripheral Authentication Service) remoteproc node should point to the QDSP PUB address space (QDSP6...SS_PUB) which has a length of 0x4040. Value of 0x100000 covers entire Touring/CDSP memory block seems to big here. This should have no functional impact on Linux users, because PAS loader does not use this address space at all. Cc: [email protected] Fixes: 96ce9227fdbc ("arm64: dts: qcom: sm6115: Add remoteproc nodes") Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-22-2e0036fccd8d@linaro.org Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Dec 13 15:54:10 2024 +0100 arm64: dts: qcom: sm6115: Fix MPSS memory length commit 472d65e7cb591c8379dd6f40561f96be73a46f0f upstream. The address space in MPSS/Modem PAS (Peripheral Authentication Service) remoteproc node should point to the QDSP PUB address space (QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x100 was copied from older DTS, but it grew since then. This should have no functional impact on Linux users, because PAS loader does not use this address space at all. Cc: [email protected] Fixes: 96ce9227fdbc ("arm64: dts: qcom: sm6115: Add remoteproc nodes") Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-21-2e0036fccd8d@linaro.org Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Dec 13 15:54:04 2024 +0100 arm64: dts: qcom: sm6350: Fix ADSP memory length commit b0805a864459a29831577d2a47165afebe338faf upstream. The address space in ADSP (Peripheral Authentication Service) remoteproc node should point to the QDSP PUB address space (QDSP6...SS_PUB) which has a length of 0x10000. This should have no functional impact on Linux users, because PAS loader does not use this address space at all. Fixes: efc33c969f23 ("arm64: dts: qcom: sm6350: Add ADSP nodes") Cc: [email protected] Tested-by: Luca Weiss <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-15-2e0036fccd8d@linaro.org Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Dec 13 15:54:05 2024 +0100 arm64: dts: qcom: sm6350: Fix MPSS memory length commit cd8d83de9cc9ecfb1f9a12bc838041c4eb4d10bd upstream. The address space in MPSS/Modem PAS (Peripheral Authentication Service) remoteproc node should point to the QDSP PUB address space (QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x4040 was copied from older DTS, but it grew since then. This should have no functional impact on Linux users, because PAS loader does not use this address space at all. Fixes: 489be59b635b ("arm64: dts: qcom: sm6350: Add MPSS nodes") Cc: [email protected] Tested-by: Luca Weiss <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-16-2e0036fccd8d@linaro.org Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Luca Weiss <[email protected]> Date: Fri Dec 20 09:59:50 2024 +0100 arm64: dts: qcom: sm6350: Fix uart1 interconnect path commit be2f81eaa2c8e81d3de5b73dca5e133f63384cb3 upstream. The path MASTER_QUP_0 to SLAVE_EBI_CH0 would be qup-memory path and not qup-config. Since the qup-memory path is not part of the qcom,geni-uart bindings, just replace that path with the correct path for qup-config. Fixes: b179f35b887b ("arm64: dts: qcom: sm6350: add uart1 node") Cc: [email protected] Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Dec 13 15:54:06 2024 +0100 arm64: dts: qcom: sm6375: Fix ADSP memory length commit bf4dda83da27b7efc49326ebb82cbd8b3e637c38 upstream. The address space in ADSP (Peripheral Authentication Service) remoteproc node should point to the QDSP PUB address space (QDSP6...SS_PUB) which has a length of 0x10000. This should have no functional impact on Linux users, because PAS loader does not use this address space at all. Fixes: fe6fd26aeddf ("arm64: dts: qcom: sm6375: Add ADSP&CDSP") Cc: [email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-17-2e0036fccd8d@linaro.org Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Dec 13 15:54:07 2024 +0100 arm64: dts: qcom: sm6375: Fix CDSP memory base and length commit c9f7f341e896836c99709421a23bae5f53039aab upstream. The address space in CDSP PAS (Peripheral Authentication Service) remoteproc node should point to the QDSP PUB address space (QDSP6...SS_PUB): 0x0b30_0000 with length of 0x10000. 0x0b00_0000, value used so far, is the main region of CDSP. Correct the base address and length, which should have no functional impact on Linux users, because PAS loader does not use this address space at all. Fixes: fe6fd26aeddf ("arm64: dts: qcom: sm6375: Add ADSP&CDSP") Cc: [email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-18-2e0036fccd8d@linaro.org Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Dec 13 15:54:08 2024 +0100 arm64: dts: qcom: sm6375: Fix MPSS memory base and length commit 918e71ba0c08c3d609ad69067854b0f675c4a253 upstream. The address space in MPSS/Modem PAS (Peripheral Authentication Service) remoteproc node should point to the QDSP PUB address space (QDSP6...SS_PUB): 0x0608_0000 with length of 0x10000. 0x0600_0000, value used so far, is the main region of Modem. Correct the base address and length, which should have no functional impact on Linux users, because PAS loader does not use this address space at all. Fixes: 31cc61104f68 ("arm64: dts: qcom: sm6375: Add modem nodes") Cc: [email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-19-2e0036fccd8d@linaro.org Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Dec 13 15:53:50 2024 +0100 arm64: dts: qcom: sm8350: Fix ADSP memory base and length commit f9ba85566ddd5a3db8fa291aaecd70c4e55a3732 upstream. The address space in ADSP PAS (Peripheral Authentication Service) remoteproc node should point to the QDSP PUB address space (QDSP6...SS_PUB): 0x0300_0000 with length of 0x10000. 0x1730_0000, value used so far, was copied from downstream DTS, is in the middle of unused space and downstream DTS describes the PIL loader, which is a bit different interface. Assume existing value (thus downstream DTS) is not really describing the intended ADSP PAS region. Correct the base address and length, which also moves the node to different place to keep things sorted by unit address. The diff looks big, but only the unit address and "reg" property were changed. This should have no functional impact on Linux users, because PAS loader does not use this address space at all. Fixes: 177fcf0aeda2 ("arm64: dts: qcom: sm8350: Add remoteprocs") Cc: [email protected] Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-1-2e0036fccd8d@linaro.org Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Dec 13 15:53:51 2024 +0100 arm64: dts: qcom: sm8350: Fix CDSP memory base and length commit f4afd8ba453b6e82245b9068868c72c831aec84e upstream. The address space in CDSP PAS (Peripheral Authentication Service) remoteproc node should point to the QDSP PUB address space (QDSP6...SS_PUB): 0x0a30_0000 with length of 0x10000. 0x9890_0000, value used so far, was copied from downstream DTS, is in the middle of RAM/DDR space and downstream DTS describes the PIL loader, which is a bit different interface. Datasheet says that one of the main CDSP address spaces is 0x0980_0000, which is oddly similar to 0x9890_0000, but quite different. Assume existing value (thus downstream DTS) is not really describing the intended CDSP PAS region. Correct the base address and length, which also moves the node to different place to keep things sorted by unit address. The diff looks big, but only the unit address and "reg" property were changed. This should have no functional impact on Linux users, because PAS loader does not use this address space at all. Fixes: 177fcf0aeda2 ("arm64: dts: qcom: sm8350: Add remoteprocs") Cc: [email protected] Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-2-2e0036fccd8d@linaro.org Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Dec 13 15:53:52 2024 +0100 arm64: dts: qcom: sm8350: Fix MPSS memory length commit da1937dec9cd986e685b6a429b528a4cbc7b1603 upstream. The address space in MPSS/Modem PAS (Peripheral Authentication Service) remoteproc node should point to the QDSP PUB address space (QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x4040 was copied from older DTS, but it grew since then. This should have no functional impact on Linux users, because PAS loader does not use this address space at all. Fixes: 177fcf0aeda2 ("arm64: dts: qcom: sm8350: Add remoteprocs") Cc: [email protected] Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-3-2e0036fccd8d@linaro.org Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Dec 13 15:53:54 2024 +0100 arm64: dts: qcom: sm8450: Fix CDSP memory length commit 3751fe2cba2a9fba2204ef62102bc4bb027cec7b upstream. The address space in CDSP PAS (Peripheral Authentication Service) remoteproc node should point to the QDSP PUB address space (QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x1400000 was copied from older DTS, but it does not look accurate at all. This should have no functional impact on Linux users, because PAS loader does not use this address space at all. Fixes: 1172729576fb ("arm64: dts: qcom: sm8450: Add remoteproc enablers and instances") Cc: [email protected] Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-5-2e0036fccd8d@linaro.org Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Dec 13 15:53:55 2024 +0100 arm64: dts: qcom: sm8450: Fix MPSS memory length commit fa6442e87ab7c4a58c0b5fc64aab1aacc8034712 upstream. The address space in MPSS/Modem PAS (Peripheral Authentication Service) remoteproc node should point to the QDSP PUB address space (QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x4040 was copied from older DTS, but it grew since then. This should have no functional impact on Linux users, because PAS loader does not use this address space at all. Fixes: 1172729576fb ("arm64: dts: qcom: sm8450: Add remoteproc enablers and instances") Cc: [email protected] Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-6-2e0036fccd8d@linaro.org Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Sat Oct 26 20:59:40 2024 +0300 arm64: dts: qcom: sm8550: correct MDSS interconnects commit b8591df49cde459e3b84cdc0517d7bf92053d244 upstream. SM8550 lists two interconnects for the display subsystem, mdp0-mem (between MDP and LLCC) and mdp1-mem (between LLCC and EBI, memory). The second interconnect is a misuse. mdpN-mem paths should be used for several outboud MDP interconnects rather than the path between LLCC and memory. This kind of misuse can result in bandwidth underflows, possibly degrading picture quality as the required memory bandwidth is divided between all mdpN-mem paths (and LLCC-EBI should not be a part of such division). Drop the second path and use direct MDP-EBI path for mdp0-mem until we support separate MDP-LLCC and LLCC-EBI paths. Fixes: d7da51db5b81 ("arm64: dts: qcom: sm8550: add display hardware devices") Cc: [email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Dec 13 15:53:57 2024 +0100 arm64: dts: qcom: sm8550: Fix CDSP memory length commit 6b2570e1e43e4acd0fcb98c6489736fe1c67b222 upstream. The address space in CDSP PAS (Peripheral Authentication Service) remoteproc node should point to the QDSP PUB address space (QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x1400000 was copied from older DTS, but it does not look accurate at all. This should have no functional impact on Linux users, because PAS loader does not use this address space at all. Fixes: d0c061e366ed ("arm64: dts: qcom: sm8550: add adsp, cdsp & mdss nodes") Cc: [email protected] Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-8-2e0036fccd8d@linaro.org Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Dec 13 15:53:58 2024 +0100 arm64: dts: qcom: sm8550: Fix MPSS memory length commit 8ef227e93a513d431f9345f23cd4d2d65607b985 upstream. The address space in MPSS/Modem PAS (Peripheral Authentication Service) remoteproc node should point to the QDSP PUB address space (QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x4040 was copied from older DTS, but it grew since then. This should have no functional impact on Linux users, because PAS loader does not use this address space at all. Fixes: d0c061e366ed ("arm64: dts: qcom: sm8550: add adsp, cdsp & mdss nodes") Cc: [email protected] Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-9-2e0036fccd8d@linaro.org Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jakob Unterwurzacher <[email protected]> Date: Fri Dec 13 10:54:58 2024 +0100 arm64: dts: rockchip: increase gmac rx_delay on rk3399-puma commit 9d241b06802c6c2176ae7aa4f9f17f8a577ed337 upstream. During mass manufacturing, we noticed the mmc_rx_crc_error counter, as reported by "ethtool -S eth0 | grep mmc_rx_crc_error", to increase above zero during nuttcp speedtests. Most of the time, this did not affect the achieved speed, but it prompted this investigation. Cycling through the rx_delay range on six boards (see table below) of various ages shows that there is a large good region from 0x12 to 0x35 where we see zero crc errors on all tested boards. The old rx_delay value (0x10) seems to have always been on the edge for the KSZ9031RNX that is usually placed on Puma. Choose "rx_delay = 0x23" to put us smack in the middle of the good region. This works fine as well with the KSZ9131RNX PHY that was used for a small number of boards during the COVID chip shortages. Board S/N PHY rx_delay good region --------- --- -------------------- Puma TT0069903 KSZ9031RNX 0x11 0x35 Puma TT0157733 KSZ9031RNX 0x11 0x35 Puma TT0681551 KSZ9031RNX 0x12 0x37 Puma TT0681156 KSZ9031RNX 0x10 0x38 Puma 17496030079 KSZ9031RNX 0x10 0x37 (Puma v1.2 from 2017) Puma TT0681720 KSZ9131RNX 0x02 0x39 (alternative PHY used in very few boards) Intersection of good regions = 0x12 0x35 Middle of good region = 0x23 Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Cc: [email protected] Reviewed-by: Quentin Schulz <[email protected]> Tested-by: Quentin Schulz <[email protected]> # Puma v2.1 and v2.3 with KSZ9031 Signed-off-by: Jakob Unterwurzacher <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sumit Gupta <[email protected]> Date: Wed Dec 18 00:07:37 2024 +0000 arm64: tegra: Disable Tegra234 sce-fabric node commit a5e6fc0a10fe280989f1367a3b4f8047c7d00ea6 upstream. Access to safety cluster engine (SCE) fabric registers was blocked by firewall after the introduction of Functional Safety Island in Tegra234. After that, any access by software to SCE registers is correctly resulting in the internal bus error. However, when CPUs try accessing the SCE-fabric registers to print error info, another firewall error occurs as the fabric registers are also firewall protected. This results in a second error to be printed. Disable the SCE fabric node to avoid printing the misleading error. The first error info will be printed by the interrupt from the fabric causing the actual access. Cc: [email protected] Fixes: 302e154000ec ("arm64: tegra: Add node for CBB 2.0 on Tegra234") Signed-off-by: Sumit Gupta <[email protected]> Signed-off-by: Ivy Huang <[email protected]> Reviewed-by: Brad Griffis <[email protected]> Reviewed-by: Jon Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Brad Griffis <[email protected]> Date: Fri Dec 13 23:56:02 2024 +0000 arm64: tegra: Fix Tegra234 PCIe interrupt-map commit b615fbd70fce8582d92b3bdbbf3c9b80cadcfb55 upstream. For interrupt-map entries, the DTS specification requires that #address-cells is defined for both the child node and the interrupt parent. For the PCIe interrupt-map entries, the parent node ("gic") has not specified #address-cells. The existing layout of the PCIe interrupt-map entries indicates that it assumes that #address-cells is zero for this node. Explicitly set #address-cells to zero for "gic" so that it complies with the device tree specification. NVIDIA EDK2 works around this issue by assuming #address-cells is zero in this scenario, but that workaround is being removed and so this update is needed or else NVIDIA EDK2 cannot successfully parse the device tree and the board cannot boot. Fixes: ec142c44b026 ("arm64: tegra: Add P2U and PCIe controller nodes to Tegra234 DT") Signed-off-by: Brad Griffis <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sumit Gupta <[email protected]> Date: Wed Dec 18 00:07:36 2024 +0000 arm64: tegra: Fix typo in Tegra234 dce-fabric compatible commit 604120fd9e9df50ee0e803d3c6e77a1f45d2c58e upstream. The compatible string for the Tegra DCE fabric is currently defined as 'nvidia,tegra234-sce-fabric' but this is incorrect because this is the compatible string for SCE fabric. Update the compatible for the DCE fabric to correct the compatible string. This compatible needs to be correct in order for the interconnect to catch things such as improper data accesses. Cc: [email protected] Fixes: 302e154000ec ("arm64: tegra: Add node for CBB 2.0 on Tegra234") Signed-off-by: Sumit Gupta <[email protected]> Signed-off-by: Ivy Huang <[email protected]> Reviewed-by: Brad Griffis <[email protected]> Reviewed-by: Jon Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Romain Naour <[email protected]> Date: Fri Nov 15 11:25:37 2024 +0100 ARM: dts: dra7: Add bus_dma_limit for l4 cfg bus commit c1472ec1dc4419d0bae663c1a1e6cb98dc7881ad upstream. A bus_dma_limit was added for l3 bus by commit cfb5d65f2595 ("ARM: dts: dra7: Add bus_dma_limit for L3 bus") to fix an issue observed only with SATA on DRA7-EVM with 4GB RAM and CONFIG_ARM_LPAE enabled. Since kernel 5.13, the SATA issue can be reproduced again following the SATA node move from L3 bus to L4_cfg in commit 8af15365a368 ("ARM: dts: Configure interconnect target module for dra7 sata"). Fix it by adding an empty dma-ranges property to l4_cfg and segment@100000 nodes (parent device tree node of SATA controller) to inherit the 2GB dma ranges limit from l3 bus node. Note: A similar fix was applied for PCIe controller by commit 90d4d3f4ea45 ("ARM: dts: dra7: Fix bus_dma_limit for PCIe"). Fixes: 8af15365a368 ("ARM: dts: Configure interconnect target module for dra7 sata"). Link: https://lore.kernel.org/linux-omap/[email protected]/ Cc: [email protected] # 5.13 Signed-off-by: Romain Naour <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kevin Hilman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Andreas Kemnade <[email protected]> Date: Wed Dec 4 18:41:52 2024 +0100 ARM: dts: ti/omap: gta04: fix pm issues caused by spi module commit 0cfbd7805fe13406500e6a6f2aa08f198d5db4bd upstream. Despite CM_IDLEST1_CORE and CM_FCLKEN1_CORE behaving normal, disabling SPI leads to messages like when suspending: Powerdomain (core_pwrdm) didn't enter target state 0 and according to /sys/kernel/debug/pm_debug/count off state is not entered. That was not connected to SPI during the discussion of disabling SPI. See: https://lore.kernel.org/linux-omap/20230122100852.32ae082c@aktux/ The reason is that SPI is per default in slave mode. Linux driver will turn it to master per default. It slave mode, the powerdomain seems to be kept active if active chip select input is sensed. Fix that by explicitly disabling the SPI3 pins which used to be muxed by the bootloader since they are available on an optionally fitted header which would require dtb overlays anyways. Fixes: a622310f7f01 ("ARM: dts: gta04: fix excess dma channel usage") CC: [email protected] Signed-off-by: Andreas Kemnade <[email protected]> Reviewed-by: Roger Quadros <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kevin Hilman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Wed Jan 22 20:49:13 2025 -0600 ASoC: acp: Support microphone from Lenovo Go S commit b9a8ea185f3f8024619b2e74b74375493c87df8c upstream. On Lenovo Go S there is a DMIC connected to the ACP but the firmware has no `AcpDmicConnected` ACPI _DSD. Add a DMI entry for all possible Lenovo Go S SKUs to enable DMIC. Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Mario Limonciello <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yu-Chun Lin <[email protected]> Date: Fri Jan 10 01:15:47 2025 +0800 ASoC: amd: Add ACPI dependency to fix build error [ Upstream commit 7e24ec93aecd12e33d31e38e5af4625553bbc727 ] As reported by the kernel test robot, the following error occurs: sound/soc/amd/yc/acp6x-mach.c: In function 'acp6x_probe': >> sound/soc/amd/yc/acp6x-mach.c:573:15: error: implicit declaration of function 'acpi_evaluate_integer'; did you mean 'acpi_evaluate_object'? [-Werror=implicit-function-declaration] 573 | ret = acpi_evaluate_integer(handle, "_WOV", NULL, &dmic_status); | ^~~~~~~~~~~~~~~~~~~~~ | acpi_evaluate_object cc1: some warnings being treated as errors The function 'acpi_evaluate_integer' and its prototype in 'acpi_bus.h' are only available when 'CONFIG_ACPI' is enabled. Add a 'depends on ACPI' directive in Kconfig to ensure proper compilation. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Yu-Chun Lin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kuninori Morimoto <[email protected]> Date: Fri Dec 13 01:21:10 2024 +0000 ASoC: soc-pcm: don't use soc_pcm_ret() on .prepare callback [ Upstream commit 301c26a018acb94dd537a4418cefa0f654500c6f ] commit 1f5664351410 ("ASoC: lower "no backend DAIs enabled for ... Port" log severity") ignores -EINVAL error message on common soc_pcm_ret(). It is used from many functions, ignoring -EINVAL is over-kill. The reason why -EINVAL was ignored was it really should only be used upon invalid parameters coming from userspace and in that case we don't want to log an error since we do not want to give userspace a way to do a denial-of-service attack on the syslog / diskspace. So don't use soc_pcm_ret() on .prepare callback is better idea. Link: https://lore.kernel.org/r/[email protected] Cc: Hans de Goede <[email protected]> Signed-off-by: Kuninori Morimoto <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Cassel <[email protected]> Date: Mon Jan 27 16:43:04 2025 +0100 ata: libata-sff: Ensure that we cannot write outside the allocated buffer commit 6e74e53b34b6dec5a50e1404e2680852ec6768d2 upstream. reveliofuzzing reported that a SCSI_IOCTL_SEND_COMMAND ioctl with out_len set to 0xd42, SCSI command set to ATA_16 PASS-THROUGH, ATA command set to ATA_NOP, and protocol set to ATA_PROT_PIO, can cause ata_pio_sector() to write outside the allocated buffer, overwriting random memory. While a ATA device is supposed to abort a ATA_NOP command, there does seem to be a bug either in libata-sff or QEMU, where either this status is not set, or the status is cleared before read by ata_sff_hsm_move(). Anyway, that is most likely a separate bug. Looking at __atapi_pio_bytes(), it already has a safety check to ensure that __atapi_pio_bytes() cannot write outside the allocated buffer. Add a similar check to ata_pio_sector(), such that also ata_pio_sector() cannot write outside the allocated buffer. Cc: [email protected] Reported-by: reveliofuzzing <[email protected]> Closes: https://lore.kernel.org/linux-ide/CA+-ZZ_jTgxh3bS7m+KX07_EWckSnW3N2adX3KV63y4g7M4CZ2A@mail.gmail.com/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Niklas Cassel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed Dec 4 15:07:15 2024 +0300 binfmt_flat: Fix integer overflow bug on 32 bit systems commit 55cf2f4b945f6a6416cc2524ba740b83cc9af25a upstream. Most of these sizes and counts are capped at 256MB so the math doesn't result in an integer overflow. The "relocs" count needs to be checked as well. Otherwise on 32bit systems the calculation of "full_data" could be wrong. full_data = data_len + relocs * sizeof(unsigned long); Fixes: c995ee28d29d ("binfmt_flat: prevent kernel dammage from corrupted executable headers") Cc: [email protected] Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Nicolas Pitre <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zijun Hu <[email protected]> Date: Sun Jan 5 16:34:03 2025 +0800 blk-cgroup: Fix class @block_class's subsystem refcount leakage commit d1248436cbef1f924c04255367ff4845ccd9025e upstream. blkcg_fill_root_iostats() iterates over @block_class's devices by class_dev_iter_(init|next)(), but does not end iterating with class_dev_iter_exit(), so causes the class's subsystem refcount leakage. Fix by ending the iterating with class_dev_iter_exit(). Fixes: ef45fe470e1e ("blk-cgroup: show global disk stats in root cgroup io.stat") Reviewed-by: Michal Koutný <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: [email protected] Acked-by: Tejun Heo <[email protected]> Signed-off-by: Zijun Hu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jens Axboe <[email protected]> Date: Thu Jan 23 06:18:41 2025 -0700 block: don't revert iter for -EIOCBQUEUED commit b13ee668e8280ca5b07f8ce2846b9957a8a10853 upstream. blkdev_read_iter() has a few odd checks, like gating the position and count adjustment on whether or not the result is bigger-than-or-equal to zero (where bigger than makes more sense), and not checking the return value of blkdev_direct_IO() before doing an iov_iter_revert(). The latter can lead to attempting to revert with a negative value, which when passed to iov_iter_revert() as an unsigned value will lead to throwing a WARN_ON() because unroll is bigger than MAX_RW_COUNT. Be sane and don't revert for -EIOCBQUEUED, like what is done in other spots. Cc: [email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Fedor Pchelkin <[email protected]> Date: Wed Jan 29 00:08:14 2025 +0300 Bluetooth: L2CAP: accept zero as a special value for MTU auto-selection commit 5c61419e02033eaf01733d66e2fcd4044808f482 upstream. One of the possible ways to enable the input MTU auto-selection for L2CAP connections is supposed to be through passing a special "0" value for it as a socket option. Commit [1] added one of those into avdtp. However, it simply wouldn't work because the kernel still treats the specified value as invalid and denies the setting attempt. Recorded BlueZ logs include the following: bluetoothd[496]: profiles/audio/avdtp.c:l2cap_connect() setsockopt(L2CAP_OPTIONS): Invalid argument (22) [1]: https://github.com/bluez/bluez/commit/ae5be371a9f53fed33d2b34748a95a5498fd4b77 Found by Linux Verification Center (linuxtesting.org). Fixes: 4b6e228e297b ("Bluetooth: Auto tune if input MTU is set to 0") Cc: [email protected] Signed-off-by: Fedor Pchelkin <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Fedor Pchelkin <[email protected]> Date: Wed Dec 18 00:19:59 2024 +0300 Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc commit 5f397409f8ee5bc82901eeaf799e1cbc4f8edcf1 upstream. A NULL sock pointer is passed into l2cap_sock_alloc() when it is called from l2cap_sock_new_connection_cb() and the error handling paths should also be aware of it. Seemingly a more elegant solution would be to swap bt_sock_alloc() and l2cap_chan_create() calls since they are not interdependent to that moment but then l2cap_chan_create() adds the soon to be deallocated and still dummy-initialized channel to the global list accessible by many L2CAP paths. The channel would be removed from the list in short period of time but be a bit more straight-forward here and just check for NULL instead of changing the order of function calls. Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool. Fixes: 7c4f78cdb8e7 ("Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()") Cc: [email protected] Signed-off-by: Fedor Pchelkin <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mazin Al Haddad <[email protected]> Date: Tue Dec 24 05:06:16 2024 +0300 Bluetooth: MGMT: Fix slab-use-after-free Read in mgmt_remove_adv_monitor_sync [ Upstream commit 26fbd3494a7dd26269cb0817c289267dbcfdec06 ] This fixes the following crash: ================================================================== BUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_sync+0x3a/0xd0 net/bluetooth/mgmt.c:5543 Read of size 8 at addr ffff88814128f898 by task kworker/u9:4/5961 CPU: 1 UID: 0 PID: 5961 Comm: kworker/u9:4 Not tainted 6.12.0-syzkaller-10684-gf1cd565ce577 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 mgmt_remove_adv_monitor_sync+0x3a/0xd0 net/bluetooth/mgmt.c:5543 hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 16026: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4314 kmalloc_noprof include/linux/slab.h:901 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] mgmt_pending_new+0x65/0x250 net/bluetooth/mgmt_util.c:269 mgmt_pending_add+0x36/0x120 net/bluetooth/mgmt_util.c:296 remove_adv_monitor+0x102/0x1b0 net/bluetooth/mgmt.c:5568 hci_mgmt_cmd+0xc47/0x11d0 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x7b8/0x11c0 net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:726 sock_write_iter+0x2d7/0x3f0 net/socket.c:1147 new_sync_write fs/read_write.c:586 [inline] vfs_write+0xaeb/0xd30 fs/read_write.c:679 ksys_write+0x18f/0x2b0 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 16022: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2338 [inline] slab_free mm/slub.c:4598 [inline] kfree+0x196/0x420 mm/slub.c:4746 mgmt_pending_foreach+0xd1/0x130 net/bluetooth/mgmt_util.c:259 __mgmt_power_off+0x183/0x430 net/bluetooth/mgmt.c:9550 hci_dev_close_sync+0x6c4/0x11c0 net/bluetooth/hci_sync.c:5208 hci_dev_do_close net/bluetooth/hci_core.c:483 [inline] hci_dev_close+0x112/0x210 net/bluetooth/hci_core.c:508 sock_do_ioctl+0x158/0x460 net/socket.c:1209 sock_ioctl+0x626/0x8e0 net/socket.c:1328 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=479aff51bb361ef5aa18 Tested-by: [email protected] Signed-off-by: Mazin Al Haddad <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Filipe Manana <[email protected]> Date: Fri Feb 7 01:21:31 2025 +0900 btrfs: avoid monopolizing a core when activating a swap file commit 2c8507c63f5498d4ee4af404a8e44ceae4345056 upstream. This commit re-attempts the backport of the change to the linux-6.6.y branch. Commit 6e1a82259307 ("btrfs: avoid monopolizing a core when activating a swap file") on this branch was reverted. During swap activation we iterate over the extents of a file and we can have many thousands of them, so we can end up in a busy loop monopolizing a core. Avoid this by doing a voluntary reschedule after processing each extent. CC: [email protected] # 5.4+ Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Koichiro Den <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 3 11:43:03 2024 -0400 btrfs: convert BUG_ON in btrfs_reloc_cow_block() to proper error handling [ Upstream commit 6a4730b325aaa48f7a5d5ba97aff0a955e2d9cec ] This BUG_ON is meant to catch backref cache problems, but these can arise from either bugs in the backref cache or corruption in the extent tree. Fix it to be a proper error. Reviewed-by: Boris Burkov <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Filipe Manana <[email protected]> Date: Mon Jan 13 15:01:08 2025 +0000 btrfs: fix assertion failure when splitting ordered extent after transaction abort [ Upstream commit 0d85f5c2dd91df6b5da454406756f463ba923b69 ] If while we are doing a direct IO write a transaction abort happens, we mark all existing ordered extents with the BTRFS_ORDERED_IOERR flag (done at btrfs_destroy_ordered_extents()), and then after that if we enter btrfs_split_ordered_extent() and the ordered extent has bytes left (meaning we have a bio that doesn't cover the whole ordered extent, see details at btrfs_extract_ordered_extent()), we will fail on the following assertion at btrfs_split_ordered_extent(): ASSERT(!(flags & ~BTRFS_ORDERED_TYPE_FLAGS)); because the BTRFS_ORDERED_IOERR flag is set and the definition of BTRFS_ORDERED_TYPE_FLAGS is just the union of all flags that identify the type of write (regular, nocow, prealloc, compressed, direct IO, encoded). Fix this by returning an error from btrfs_extract_ordered_extent() if we find the BTRFS_ORDERED_IOERR flag in the ordered extent. The error will be the error that resulted in the transaction abort or -EIO if no transaction abort happened. This was recently reported by syzbot with the following trace: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 CPU: 0 UID: 0 PID: 5321 Comm: syz.0.0 Not tainted 6.13.0-rc5-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 fail_dump lib/fault-inject.c:53 [inline] should_fail_ex+0x3b0/0x4e0 lib/fault-inject.c:154 should_failslab+0xac/0x100 mm/failslab.c:46 slab_pre_alloc_hook mm/slub.c:4072 [inline] slab_alloc_node mm/slub.c:4148 [inline] __do_kmalloc_node mm/slub.c:4297 [inline] __kmalloc_noprof+0xdd/0x4c0 mm/slub.c:4310 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] btrfs_chunk_alloc_add_chunk_item+0x244/0x1100 fs/btrfs/volumes.c:5742 reserve_chunk_space+0x1ca/0x2c0 fs/btrfs/block-group.c:4292 check_system_chunk fs/btrfs/block-group.c:4319 [inline] do_chunk_alloc fs/btrfs/block-group.c:3891 [inline] btrfs_chunk_alloc+0x77b/0xf80 fs/btrfs/block-group.c:4187 find_free_extent_update_loop fs/btrfs/extent-tree.c:4166 [inline] find_free_extent+0x42d1/0x5810 fs/btrfs/extent-tree.c:4579 btrfs_reserve_extent+0x422/0x810 fs/btrfs/extent-tree.c:4672 btrfs_new_extent_direct fs/btrfs/direct-io.c:186 [inline] btrfs_get_blocks_direct_write+0x706/0xfa0 fs/btrfs/direct-io.c:321 btrfs_dio_iomap_begin+0xbb7/0x1180 fs/btrfs/direct-io.c:525 iomap_iter+0x697/0xf60 fs/iomap/iter.c:90 __iomap_dio_rw+0xeb9/0x25b0 fs/iomap/direct-io.c:702 btrfs_dio_write fs/btrfs/direct-io.c:775 [inline] btrfs_direct_write+0x610/0xa30 fs/btrfs/direct-io.c:880 btrfs_do_write_iter+0x2a0/0x760 fs/btrfs/file.c:1397 do_iter_readv_writev+0x600/0x880 vfs_writev+0x376/0xba0 fs/read_write.c:1050 do_pwritev fs/read_write.c:1146 [inline] __do_sys_pwritev2 fs/read_write.c:1204 [inline] __se_sys_pwritev2+0x196/0x2b0 fs/read_write.c:1195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f1281f85d29 RSP: 002b:00007f12819fe038 EFLAGS: 00000246 ORIG_RAX: 0000000000000148 RAX: ffffffffffffffda RBX: 00007f1282176080 RCX: 00007f1281f85d29 RDX: 0000000000000001 RSI: 0000000020000240 RDI: 0000000000000005 RBP: 00007f12819fe090 R08: 0000000000000000 R09: 0000000000000003 R10: 0000000000007000 R11: 0000000000000246 R12: 0000000000000002 R13: 0000000000000000 R14: 00007f1282176080 R15: 00007ffcb9e23328 </TASK> BTRFS error (device loop0 state A): Transaction aborted (error -12) BTRFS: error (device loop0 state A) in btrfs_chunk_alloc_add_chunk_item:5745: errno=-12 Out of memory BTRFS info (device loop0 state EA): forced readonly assertion failed: !(flags & ~BTRFS_ORDERED_TYPE_FLAGS), in fs/btrfs/ordered-data.c:1234 ------------[ cut here ]------------ kernel BUG at fs/btrfs/ordered-data.c:1234! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5321 Comm: syz.0.0 Not tainted 6.13.0-rc5-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:btrfs_split_ordered_extent+0xd8d/0xe20 fs/btrfs/ordered-data.c:1234 RSP: 0018:ffffc9000d1df2b8 EFLAGS: 00010246 RAX: 0000000000000057 RBX: 000000000006a000 RCX: 9ce21886c4195300 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: 0000000000000091 R08: ffffffff817f0a3c R09: 1ffff92001a3bdf4 R10: dffffc0000000000 R11: fffff52001a3bdf5 R12: 1ffff1100a45f401 R13: ffff8880522fa018 R14: dffffc0000000000 R15: 000000000006a000 FS: 00007f12819fe6c0(0000) GS:ffff88801fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000557750bd7da8 CR3: 00000000400ea000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> btrfs_extract_ordered_extent fs/btrfs/direct-io.c:702 [inline] btrfs_dio_submit_io+0x4be/0x6d0 fs/btrfs/direct-io.c:737 iomap_dio_submit_bio fs/iomap/direct-io.c:85 [inline] iomap_dio_bio_iter+0x1022/0x1740 fs/iomap/direct-io.c:447 __iomap_dio_rw+0x13b7/0x25b0 fs/iomap/direct-io.c:703 btrfs_dio_write fs/btrfs/direct-io.c:775 [inline] btrfs_direct_write+0x610/0xa30 fs/btrfs/direct-io.c:880 btrfs_do_write_iter+0x2a0/0x760 fs/btrfs/file.c:1397 do_iter_readv_writev+0x600/0x880 vfs_writev+0x376/0xba0 fs/read_write.c:1050 do_pwritev fs/read_write.c:1146 [inline] __do_sys_pwritev2 fs/read_write.c:1204 [inline] __se_sys_pwritev2+0x196/0x2b0 fs/read_write.c:1195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f1281f85d29 RSP: 002b:00007f12819fe038 EFLAGS: 00000246 ORIG_RAX: 0000000000000148 RAX: ffffffffffffffda RBX: 00007f1282176080 RCX: 00007f1281f85d29 RDX: 0000000000000001 RSI: 0000000020000240 RDI: 0000000000000005 RBP: 00007f12819fe090 R08: 0000000000000000 R09: 0000000000000003 R10: 0000000000007000 R11: 0000000000000246 R12: 0000000000000002 R13: 0000000000000000 R14: 00007f1282176080 R15: 00007ffcb9e23328 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:btrfs_split_ordered_extent+0xd8d/0xe20 fs/btrfs/ordered-data.c:1234 RSP: 0018:ffffc9000d1df2b8 EFLAGS: 00010246 RAX: 0000000000000057 RBX: 000000000006a000 RCX: 9ce21886c4195300 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: 0000000000000091 R08: ffffffff817f0a3c R09: 1ffff92001a3bdf4 R10: dffffc0000000000 R11: fffff52001a3bdf5 R12: 1ffff1100a45f401 R13: ffff8880522fa018 R14: dffffc0000000000 R15: 000000000006a000 FS: 00007f12819fe6c0(0000) GS:ffff88801fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000557750bd7da8 CR3: 00000000400ea000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 In this case the transaction abort was due to (an injected) memory allocation failure when attempting to allocate a new chunk. Reported-by: [email protected] Link: https://lore.kernel.org/linux-btrfs/[email protected]/ Fixes: 52b1fdca23ac ("btrfs: handle completed ordered extents in btrfs_split_ordered_extent") Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hao-ran Zheng <[email protected]> Date: Tue Dec 3 15:56:51 2024 +0800 btrfs: fix data race when accessing the inode's disk_i_size at btrfs_drop_extents() [ Upstream commit 5324c4e10e9c2ce307a037e904c0d9671d7137d9 ] A data race occurs when the function `insert_ordered_extent_file_extent()` and the function `btrfs_inode_safe_disk_i_size_write()` are executed concurrently. The function `insert_ordered_extent_file_extent()` is not locked when reading inode->disk_i_size, causing `btrfs_inode_safe_disk_i_size_write()` to cause data competition when writing inode->disk_i_size, thus affecting the value of `modify_tree`. The specific call stack that appears during testing is as follows: ============DATA_RACE============ btrfs_drop_extents+0x89a/0xa060 [btrfs] insert_reserved_file_extent+0xb54/0x2960 [btrfs] insert_ordered_extent_file_extent+0xff5/0x1760 [btrfs] btrfs_finish_one_ordered+0x1b85/0x36a0 [btrfs] btrfs_finish_ordered_io+0x37/0x60 [btrfs] finish_ordered_fn+0x3e/0x50 [btrfs] btrfs_work_helper+0x9c9/0x27a0 [btrfs] process_scheduled_works+0x716/0xf10 worker_thread+0xb6a/0x1190 kthread+0x292/0x330 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 ============OTHER_INFO============ btrfs_inode_safe_disk_i_size_write+0x4ec/0x600 [btrfs] btrfs_finish_one_ordered+0x24c7/0x36a0 [btrfs] btrfs_finish_ordered_io+0x37/0x60 [btrfs] finish_ordered_fn+0x3e/0x50 [btrfs] btrfs_work_helper+0x9c9/0x27a0 [btrfs] process_scheduled_works+0x716/0xf10 worker_thread+0xb6a/0x1190 kthread+0x292/0x330 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 ================================= The main purpose of the check of the inode's disk_i_size is to avoid taking write locks on a btree path when we have a write at or beyond EOF, since in these cases we don't expect to find extent items in the root to drop. However if we end up taking write locks due to a data race on disk_i_size, everything is still correct, we only add extra lock contention on the tree in case there's concurrency from other tasks. If the race causes us to not take write locks when we actually need them, then everything is functionally correct as well, since if we find out we have extent items to drop and we took read locks (modify_tree set to 0), we release the path and retry again with write locks. Since this data race does not affect the correctness of the function, it is a harmless data race, use data_race() to check inode->disk_i_size. Reviewed-by: Filipe Manana <[email protected]> Signed-off-by: Hao-ran Zheng <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Filipe Manana <[email protected]> Date: Mon Jan 20 17:26:10 2025 +0000 btrfs: fix use-after-free when attempting to join an aborted transaction [ Upstream commit e2f0943cf37305dbdeaf9846e3c941451bcdef63 ] When we are trying to join the current transaction and if it's aborted, we read its 'aborted' field after unlocking fs_info->trans_lock and without holding any extra reference count on it. This means that a concurrent task that is aborting the transaction may free the transaction before we read its 'aborted' field, leading to a use-after-free. Fix this by reading the 'aborted' field while holding fs_info->trans_lock since any freeing task must first acquire that lock and set fs_info->running_transaction to NULL before freeing the transaction. This was reported by syzbot and Dmitry with the following stack traces from KASAN: ================================================================== BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128 CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events_unbound btrfs_async_reclaim_data_space Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803 btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 5315: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572 lookup_open fs/namei.c:3649 [inline] open_last_lookups fs/namei.c:3748 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3984 do_filp_open+0x27f/0x4e0 fs/namei.c:4014 do_sys_openat2+0x13e/0x1d0 fs/open.c:1402 do_sys_open fs/open.c:1417 [inline] __do_sys_creat fs/open.c:1495 [inline] __se_sys_creat fs/open.c:1489 [inline] __x64_sys_creat+0x123/0x170 fs/open.c:1489 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5336: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 cleanup_transaction fs/btrfs/transaction.c:2063 [inline] btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598 insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757 btrfs_balance+0x992/0x10c0 fs/btrfs/volumes.c:4633 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3670 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff888011839000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 36 bytes inside of freed 2048-byte region [ffff888011839000, ffff888011839800) The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11838 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff) page_type: f5(slab) raw: 00fff00000000040 ffff88801ac42000 ffffea0000493400 dead000000000002 raw: 0000000000000000 0000000000080008 00000001f5000000 0000000000000000 head: 00fff00000000040 ffff88801ac42000 ffffea0000493400 dead000000000002 head: 0000000000000000 0000000000080008 00000001f5000000 0000000000000000 head: 00fff00000000003 ffffea0000460e01 ffffffffffffffff 0000000000000000 head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 57, tgid 57 (kworker/0:2), ts 67248182943, free_ts 67229742023 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1558 prep_new_page mm/page_alloc.c:1566 [inline] get_page_from_freelist+0x365c/0x37a0 mm/page_alloc.c:3476 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4753 alloc_pages_mpol_noprof+0x3e1/0x780 mm/mempolicy.c:2269 alloc_slab_page+0x6a/0x110 mm/slub.c:2423 allocate_slab+0x5a/0x2b0 mm/slub.c:2589 new_slab mm/slub.c:2642 [inline] ___slab_alloc+0xc27/0x14a0 mm/slub.c:3830 __slab_alloc+0x58/0xa0 mm/slub.c:3920 __slab_alloc_node mm/slub.c:3995 [inline] slab_alloc_node mm/slub.c:4156 [inline] __do_kmalloc_node mm/slub.c:4297 [inline] __kmalloc_node_track_caller_noprof+0x2e9/0x4c0 mm/slub.c:4317 kmalloc_reserve+0x111/0x2a0 net/core/skbuff.c:609 __alloc_skb+0x1f3/0x440 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1323 [inline] alloc_skb_with_frags+0xc3/0x820 net/core/skbuff.c:6612 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2884 sock_alloc_send_skb include/net/sock.h:1803 [inline] mld_newpack+0x1c3/0xaf0 net/ipv6/mcast.c:1747 add_grhead net/ipv6/mcast.c:1850 [inline] add_grec+0x1492/0x19a0 net/ipv6/mcast.c:1988 mld_send_cr net/ipv6/mcast.c:2114 [inline] mld_ifc_work+0x691/0xd90 net/ipv6/mcast.c:2651 page last free pid 5300 tgid 5300 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1127 [inline] free_unref_page+0xd3f/0x1010 mm/page_alloc.c:2659 __slab_free+0x2c2/0x380 mm/slub.c:4524 qlink_free mm/kasan/quarantine.c:163 [inline] qlist_free_all+0x9a/0x140 mm/kasan/quarantine.c:179 kasan_quarantine_reduce+0x14f/0x170 mm/kasan/quarantine.c:286 __kasan_slab_alloc+0x23/0x80 mm/kasan/common.c:329 kasan_slab_alloc include/linux/kasan.h:250 [inline] slab_post_alloc_hook mm/slub.c:4119 [inline] slab_alloc_node mm/slub.c:4168 [inline] __do_kmalloc_node mm/slub.c:4297 [inline] __kmalloc_noprof+0x236/0x4c0 mm/slub.c:4310 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] fib_create_info+0xc14/0x25b0 net/ipv4/fib_semantics.c:1435 fib_table_insert+0x1f6/0x1f20 net/ipv4/fib_trie.c:1231 fib_magic+0x3d8/0x620 net/ipv4/fib_frontend.c:1112 fib_add_ifaddr+0x40c/0x5e0 net/ipv4/fib_frontend.c:1156 fib_netdev_event+0x375/0x490 net/ipv4/fib_frontend.c:1494 notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:9045 do_setlink+0xc90/0x4210 net/core/rtnetlink.c:3109 rtnl_changelink net/core/rtnetlink.c:3723 [inline] __rtnl_newlink net/core/rtnetlink.c:3875 [inline] rtnl_newlink+0x1bb6/0x2210 net/core/rtnetlink.c:4012 Memory state around the buggy address: ffff888011838f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888011838f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888011839000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888011839080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888011839100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Reported-by: [email protected] Link: https://lore.kernel.org/linux-btrfs/[email protected]/ Reported-by: Dmitry Vyukov <[email protected]> Link: https://lore.kernel.org/linux-btrfs/CACT4Y+ZFBdo7pT8L2AzM=vegZwjp-wNkVJZQf0Ta3vZqtExaSw@mail.gmail.com/ Fixes: 871383be592b ("btrfs: add missing unlocks to transaction abort paths") Reviewed-by: Johannes Thumshirn <[email protected]> Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zizhi Wo <[email protected]> Date: Thu Nov 7 19:06:48 2024 +0800 cachefiles: Fix NULL pointer dereference in object->file commit 31ad74b20227ce6b40910ff78b1c604e42975cf1 upstream. At present, the object->file has the NULL pointer dereference problem in ondemand-mode. The root cause is that the allocated fd and object->file lifetime are inconsistent, and the user-space invocation to anon_fd uses object->file. Following is the process that triggers the issue: [write fd] [umount] cachefiles_ondemand_fd_write_iter fscache_cookie_state_machine cachefiles_withdraw_cookie if (!file) return -ENOBUFS cachefiles_clean_up_object cachefiles_unmark_inode_in_use fput(object->file) object->file = NULL // file NULL pointer dereference! __cachefiles_write(..., file, ...) Fix this issue by add an additional reference count to the object->file before write/llseek, and decrement after it finished. Fixes: c8383054506c ("cachefiles: notify the user daemon when looking up cookie") Signed-off-by: Zizhi Wo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: David Howells <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Bin Lan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Daniel Golle <[email protected]> Date: Sun Dec 15 22:14:11 2024 +0000 clk: mediatek: mt2701-aud: fix conversion to mtk_clk_simple_probe commit 5fba40be5fbad563914e3ce9d5129a6baaea1ff5 upstream. Some of the audio subsystem clocks defined in clk-mt2701.h aren't actually used by the driver. This broke conversion to mtk_clk_simple_probe which expects that the highest possible clk id is defined by the ARRAY_SIZE. Add additional dummy clocks to fill the gaps and remain compatible with the existing DT bindings. Fixes: 0f69a423c458 ("clk: mediatek: Switch to mtk_clk_simple_probe() where possible") Cc: [email protected] Signed-off-by: Daniel Golle <[email protected]> Link: https://lore.kernel.org/r/a07584d803af57b9ce4b5df5e122c09bf5a56ac9.1734300668.git.daniel@makrotopia.org Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Daniel Golle <[email protected]> Date: Sun Dec 15 22:14:24 2024 +0000 clk: mediatek: mt2701-bdp: add missing dummy clk commit fd291adc5e9a4ee6cd91e57f148f3b427f80647b upstream. Add dummy clk for index 0 which was missed during the conversion to mtk_clk_simple_probe(). Fixes: 973d1607d936 ("clk: mediatek: mt2701: use mtk_clk_simple_probe to simplify driver") Cc: [email protected] Signed-off-by: Daniel Golle <[email protected]> Link: https://lore.kernel.org/r/b8526c882a50f2b158df0eccb4a165956fd8fa13.1734300668.git.daniel@makrotopia.org Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Daniel Golle <[email protected]> Date: Sun Dec 15 22:14:48 2024 +0000 clk: mediatek: mt2701-img: add missing dummy clk commit 366640868ccb4a7991aebe8442b01340fab218e2 upstream. Add dummy clk for index 0 which was missed during the conversion to mtk_clk_simple_probe(). Fixes: 973d1607d936 ("clk: mediatek: mt2701: use mtk_clk_simple_probe to simplify driver") Cc: [email protected] Signed-off-by: Daniel Golle <[email protected]> Link: https://lore.kernel.org/r/d677486a5c563fe5c47aa995841adc2aaa183b8a.1734300668.git.daniel@makrotopia.org Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Daniel Golle <[email protected]> Date: Sun Dec 15 22:14:34 2024 +0000 clk: mediatek: mt2701-mm: add missing dummy clk commit 67aea188f23a5dde51c31a720ccf66aed0ce4187 upstream. Add dummy clk which was missed during the conversion to mtk_clk_pdev_probe() and is required for the existing DT bindings to keep working. Fixes: 65c10c50c9c7 ("clk: mediatek: Migrate to mtk_clk_pdev_probe() for multimedia clocks") Cc: [email protected] Signed-off-by: Daniel Golle <[email protected]> Link: https://lore.kernel.org/r/9de23440fcba1ffef9e77d58c9f505105e57a250.1734300668.git.daniel@makrotopia.org Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Daniel Golle <[email protected]> Date: Sun Dec 15 22:13:49 2024 +0000 clk: mediatek: mt2701-vdec: fix conversion to mtk_clk_simple_probe commit 7c8746126a4e256fcf1af9174ee7d92cc3f3bc31 upstream. Commit 973d1607d936 ("clk: mediatek: mt2701: use mtk_clk_simple_probe to simplify driver") broke DT bindings as the highest index was reduced by 1 because the id count starts from 1 and not from 0. Fix this, like for other drivers which had the same issue, by adding a dummy clk at index 0. Fixes: 973d1607d936 ("clk: mediatek: mt2701: use mtk_clk_simple_probe to simplify driver") Cc: [email protected] Signed-off-by: Daniel Golle <[email protected]> Link: https://lore.kernel.org/r/b126a5577f3667ef19b1b5feea5e70174084fb03.1734300668.git.daniel@makrotopia.org Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gabor Juhos <[email protected]> Date: Mon Oct 21 19:32:48 2024 +0200 clk: qcom: clk-alpha-pll: fix alpha mode configuration commit 33f1722eb86e45320a3dd7b3d42f6593a1d595c2 upstream. Commit c45ae598fc16 ("clk: qcom: support for alpha mode configuration") added support for configuring alpha mode, but it seems that the feature was never working in practice. The value of the alpha_{en,mode}_mask members of the configuration gets added to the value parameter passed to the regmap_update_bits() function, however the same values are not getting applied to the bitmask. As the result, the respective bits in the USER_CTL register are never modifed which leads to improper configuration of several PLLs. The following table shows the PLL configurations where the 'alpha_en_mask' member is set and which are passed as a parameter for the clk_alpha_pll_configure() function. In the table the 'expected rate' column shows the rate the PLL should run at with the given configuration, and the 'real rate' column shows the rate the PLL runs at actually. The real rates has been verified on hardwareOn IPQ* platforms, on other platforms, those are computed values only. file pll expected rate real rate dispcc-qcm2290.c disp_cc_pll0 768.0 MHz 768.0 MHz dispcc-sm6115.c disp_cc_pll0 768.0 MHz 768.0 MHz gcc-ipq5018.c ubi32_pll 1000.0 MHz != 984.0 MHz gcc-ipq6018.c nss_crypto_pll 1200.0 MHz 1200.0 MHz gcc-ipq6018.c ubi32_pll 1497.6 MHz != 1488.0 MHz gcc-ipq8074.c nss_crypto_pll 1200.0 MHz != 1190.4 MHz gcc-qcm2290.c gpll11 532.0 MHz != 518.4 MHz gcc-qcm2290.c gpll8 533.2 MHz != 518.4 MHz gcc-qcs404.c gpll3 921.6 MHz 921.6 MHz gcc-sm6115.c gpll11 600.0 MHz != 595.2 MHz gcc-sm6115.c gpll8 800.0 MHz != 787.2 MHz gpucc-sdm660.c gpu_cc_pll0 800.0 MHz != 787.2 MHz gpucc-sdm660.c gpu_cc_pll1 740.0 MHz != 729.6 MHz gpucc-sm6115.c gpu_cc_pll0 1200.0 MHz != 1190.4 MHz gpucc-sm6115.c gpu_cc_pll1 640.0 MHz != 633.6 MHz gpucc-sm6125.c gpu_pll0 1020.0 MHz != 1017.6 MHz gpucc-sm6125.c gpu_pll1 930.0 MHz != 921.6 MHz mmcc-sdm660.c mmpll8 930.0 MHz != 921.6 MHz mmcc-sdm660.c mmpll5 825.0 MHz != 806.4 MHz As it can be seen from the above, there are several PLLs which are configured incorrectly. Change the code to apply both 'alpha_en_mask' and 'alpha_mode_mask' values to the bitmask in order to configure the alpha mode correctly. Applying the 'alpha_en_mask' fixes the initial rate of the PLLs showed in the table above. Since the 'alpha_mode_mask' is not used by any driver currently, that part of the change causes no functional changes. Cc: [email protected] Fixes: c45ae598fc16 ("clk: qcom: support for alpha mode configuration") Signed-off-by: Gabor Juhos <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Tested-by: Gabor Juhos <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Anastasia Belova <[email protected]> Date: Tue Dec 3 11:42:31 2024 +0300 clk: qcom: clk-rpmh: prevent integer overflow in recalc_rate commit 89aa5925d201b90a48416784831916ca203658f9 upstream. aggr_state and unit fields are u32. The result of their multiplication may not fit in this type. Add explicit casting to prevent overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 04053f4d23a4 ("clk: qcom: clk-rpmh: Add IPA clock support") Cc: [email protected] # 5.4+ Signed-off-by: Anastasia Belova <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Luca Weiss <[email protected]> Date: Fri Dec 20 10:03:31 2024 +0100 clk: qcom: dispcc-sm6350: Add missing parent_map for a clock commit d4cdb196f182d2fbe336c968228be00d8c3fed05 upstream. If a clk_rcg2 has a parent, it should also have parent_map defined, otherwise we'll get a NULL pointer dereference when calling clk_set_rate like the following: [ 3.388105] Call trace: [ 3.390664] qcom_find_src_index+0x3c/0x70 (P) [ 3.395301] qcom_find_src_index+0x1c/0x70 (L) [ 3.399934] _freq_tbl_determine_rate+0x48/0x100 [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28 [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4 [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300 [ 3.455886] clk_set_rate+0x38/0x14c Add the parent_map property for the clock where it's missing and also un-inline the parent_data as well to keep the matching parent_map and parent_data together. Fixes: 837519775f1d ("clk: qcom: Add display clock controller driver for SM6350") Cc: [email protected] Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Satya Priya Kakitapalli <[email protected]> Date: Fri Dec 20 15:20:48 2024 +0530 clk: qcom: gcc-mdm9607: Fix cmd_rcgr offset for blsp1_uart6 rcg commit 88d9dca36aac9659446be1e569d8fbe3462b5741 upstream. Fix cmd_rcgr offset for blsp1_uart6_apps_clk_src on mdm9607 platform. Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Cc: [email protected] Signed-off-by: Satya Priya Kakitapalli <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Luca Weiss <[email protected]> Date: Fri Dec 20 10:03:30 2024 +0100 clk: qcom: gcc-sm6350: Add missing parent_map for two clocks commit 96fe1a7ee477d701cfc98ab9d3c730c35d966861 upstream. If a clk_rcg2 has a parent, it should also have parent_map defined, otherwise we'll get a NULL pointer dereference when calling clk_set_rate like the following: [ 3.388105] Call trace: [ 3.390664] qcom_find_src_index+0x3c/0x70 (P) [ 3.395301] qcom_find_src_index+0x1c/0x70 (L) [ 3.399934] _freq_tbl_determine_rate+0x48/0x100 [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28 [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4 [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300 [ 3.455886] clk_set_rate+0x38/0x14c Add the parent_map property for two clocks where it's missing and also un-inline the parent_data as well to keep the matching parent_map and parent_data together. Fixes: 131abae905df ("clk: qcom: Add SM6350 GCC driver") Cc: [email protected] Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Thu Dec 19 22:30:10 2024 +0530 clk: qcom: gcc-sm8550: Do not turn off PCIe GDSCs during gdsc_disable() commit 967e011013eda287dbec9e8bd3a19ebe730b8a08 upstream. With PWRSTS_OFF_ON, PCIe GDSCs are turned off during gdsc_disable(). This can happen during scenarios such as system suspend and breaks the resume of PCIe controllers from suspend. So use PWRSTS_RET_ON to indicate the GDSC driver to not turn off the GDSCs during gdsc_disable() and allow the hardware to transition the GDSCs to retention when the parent domain enters low power state during system suspend. Cc: [email protected] # 6.2 Fixes: 955f2ea3b9e9 ("clk: qcom: Add GCC driver for SM8550") Reported-by: Neil Armstrong <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on QRD8550 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Sat Oct 26 12:58:13 2024 +0200 clk: qcom: Make GCC_8150 depend on QCOM_GDSC [ Upstream commit 1474149c4209943b37a2c01b82f07ba39465e5fe ] Like all other non-ancient Qualcomm clock drivers, QCOM_GDSC is required, as the GCC driver defines and instantiates a bunch of GDSCs. Add the missing dependency. Reported-by: Vladimir Zapolskiy <[email protected]> Closes: https://lore.kernel.org/linux-arm-msm/[email protected]/ Signed-off-by: Konrad Dybcio <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Vladimir Zapolskiy <[email protected]> Link: https://lore.kernel.org/r/20241026-topic-8150gcc_kconfig-v1-1-3772013d8804@oss.qualcomm.com Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cody Eksal <[email protected]> Date: Fri Nov 8 20:37:37 2024 -0400 clk: sunxi-ng: a100: enable MMC clock reparenting commit 16414720045de30945b8d14b7907e0cbf81a4b49 upstream. While testing the MMC nodes proposed in [1], it was noted that mmc0/1 would fail to initialize, with "mmc: fatal err update clk timeout" in the kernel logs. A closer look at the clock definitions showed that the MMC MPs had the "CLK_SET_RATE_NO_REPARENT" flag set. No reason was given for adding this flag in the first place, and its original purpose is unknown, but it doesn't seem to make sense and results in severe limitations to MMC speeds. Thus, remove this flag from the 3 MMC MPs. [1] https://msgid.link/[email protected] Fixes: fb038ce4db55 ("clk: sunxi-ng: add support for the Allwinner A100 CCU") Cc: [email protected] Signed-off-by: Cody Eksal <[email protected]> Reviewed-by: Andre Przywara <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Viresh Kumar <[email protected]> Date: Wed Jan 22 11:36:16 2025 +0530 cpufreq: s3c64xx: Fix compilation warning commit 43855ac61483cb914f060851535ea753c094b3e0 upstream. The driver generates following warning when regulator support isn't enabled in the kernel. Fix it. drivers/cpufreq/s3c64xx-cpufreq.c: In function 's3c64xx_cpufreq_set_target': >> drivers/cpufreq/s3c64xx-cpufreq.c:55:22: warning: variable 'old_freq' set but not used [-Wunused-but-set-variable] 55 | unsigned int old_freq, new_freq; | ^~~~~~~~ >> drivers/cpufreq/s3c64xx-cpufreq.c:54:30: warning: variable 'dvfs' set but not used [-Wunused-but-set-variable] 54 | struct s3c64xx_dvfs *dvfs; | ^~~~ Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Cc: 5.4+ <[email protected]> # v5.4+ Signed-off-by: Viresh Kumar <[email protected]> Link: https://patch.msgid.link/236b227e929e5adc04d1e9e7af6845a46c8e9432.1737525916.git.viresh.kumar@linaro.org Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bartosz Golaszewski <[email protected]> Date: Tue Dec 3 10:19:29 2024 +0100 crypto: qce - fix goto jump in error path commit 5278275c1758a38199b43530adfc50098f4b41c7 upstream. If qce_check_version() fails, we should jump to err_dma as we already called qce_dma_request() a couple lines before. Cc: [email protected] Fixes: ec8f5d8f6f76 ("crypto: qce - Qualcomm crypto engine driver") Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Tue Dec 3 10:05:53 2024 -0800 crypto: qce - fix priority to be less than ARMv8 CE commit 49b9258b05b97c6464e1964b6a2fddb3ddb65d17 upstream. As QCE is an order of magnitude slower than the ARMv8 Crypto Extensions on the CPU, and is also less well tested, give it a lower priority. Previously the QCE SHA algorithms had higher priority than the ARMv8 CE equivalents, and the ciphers such as AES-XTS had the same priority which meant the QCE versions were chosen if they happened to be loaded later. Fixes: ec8f5d8f6f76 ("crypto: qce - Qualcomm crypto engine driver") Cc: [email protected] Cc: Bartosz Golaszewski <[email protected]> Cc: Neil Armstrong <[email protected]> Cc: Thara Gopinath <[email protected]> Signed-off-by: Eric Biggers <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bartosz Golaszewski <[email protected]> Date: Tue Dec 3 10:19:30 2024 +0100 crypto: qce - unregister previously registered algos in error path commit e80cf84b608725303113d6fe98bb727bf7b7a40d upstream. If we encounter an error when registering alorithms with the crypto framework, we just bail out and don't unregister the ones we successfully registered in prior iterations of the loop. Add code that goes back over the algos and unregisters them before returning an error from qce_register_algs(). Cc: [email protected] Fixes: ec8f5d8f6f76 ("crypto: qce - Qualcomm crypto engine driver") Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hou Tao <[email protected]> Date: Mon Jan 20 16:29:49 2025 +0800 dm-crypt: don't update io->sector after kcryptd_crypt_write_io_submit() commit 9fdbbdbbc92b1474a87b89f8b964892a63734492 upstream. The updates of io->sector are the leftovers when dm-crypt allocated pages for partial write request. However, since commit cf2f1abfbd0db ("dm crypt: don't allocate pages for a partial request"), there is no partial request anymore. After the introduction of write request rb-tree, the updates of io->sectors may interfere the insertion procedure, because ->sectors of these write requests which have already been added in the rb-tree may be changed during the insertion of new write request. Fix it by removing these buggy updates of io->sectors. Considering these updates only effect the write request rb-tree, the commit which introduces the write request rb-tree is used as the fix tag. Fixes: b3c5fd305249 ("dm crypt: sort writes") Cc: [email protected] Signed-off-by: Hou Tao <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hou Tao <[email protected]> Date: Mon Jan 20 16:29:51 2025 +0800 dm-crypt: track tag_offset in convert_context commit 8b8f8037765757861f899ed3a2bfb34525b5c065 upstream. dm-crypt uses tag_offset to index the integrity metadata for each crypt sector. When the initial crypt_convert() returns BLK_STS_DEV_RESOURCE, dm-crypt will try to continue the crypt/decrypt procedure in a kworker. However, it resets tag_offset as zero instead of using the tag_offset related with current sector. It may return unexpected data when using random IV or return unexpected integrity related error. Fix the problem by tracking tag_offset in per-IO convert_context. Therefore, when the crypt/decrypt procedure continues in a kworker, it could use the next tag_offset saved in convert_context. Fixes: 8abec36d1274 ("dm crypt: do not wait for backlogged crypto request completion in softirq") Cc: [email protected] Signed-off-by: Hou Tao <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Fangzhi Zuo <[email protected]> Date: Mon Dec 2 13:30:37 2024 -0500 drm/amd/display: Fix Mode Cutoff in DSC Passthrough to DP2.1 Monitor [ Upstream commit e56ad45e991128bf4db160b75a1d9f647a341d8f ] Source --> DP2.1 MST hub --> DP1.4/2.1 monitor When change from DP1.4 to DP2.1 from monitor manual, modes higher than 4k120 are all cutoff by mode validation. Switch back to DP1.4 gets all the modes up to 4k240 available to be enabled by dsc passthrough. [why] Compared to DP1.4 link from hub to monitor, DP2.1 link has larger full_pbn value that causes overflow in the process of doing conversion from pbn to kbps. [how] Change the data type accordingly to fit into the data limit during conversion calculation. Tested-by: Daniel Wheeler <[email protected]> Reviewed-by: Wayne Lin <[email protected]> Signed-off-by: Fangzhi Zuo <[email protected]> Signed-off-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Dec 6 11:43:07 2024 +0200 drm/amd/display: use eld_mutex to protect access to connector->eld [ Upstream commit 819bee01eea06282d7bda17d46caf29cae4f6d84 ] Reading access to connector->eld can happen at the same time the drm_edid_to_eld() updates the data. Take the newly added eld_mutex in order to protect connector->eld from concurrent access. Reviewed-by: Maxime Ripard <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lijo Lazar <[email protected]> Date: Wed Jan 22 09:12:41 2025 +0530 drm/amd/pm: Mark MM activity as unsupported commit 819bf6662b93a5a8b0c396d2c7e7fab6264c9808 upstream. Aldebaran doesn't support querying MM activity percentage. Keep the field as 0xFFs to mark it as unsupported. Signed-off-by: Lijo Lazar <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Prike Liang <[email protected]> Date: Tue Jan 14 11:20:17 2025 +0800 drm/amdkfd: only flush the validate MES contex commit 9078a5bfa21e78ae68b6d7c365d1b92f26720c55 upstream. The following page fault was observed duringthe KFD process release. In this particular error case, the HIP test (./MemcpyPerformance -h) does not require the queue. As a result, the process_context_addr was not assigned when the KFD process was released, ultimately leading to this page fault during the execution of the function kfd_process_dequeue_from_all_devices(). [345962.294891] amdgpu 0000:03:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:153 vmid:0 pasid:0) [345962.295333] amdgpu 0000:03:00.0: amdgpu: in page starting at address 0x0000000000000000 from client 10 [345962.295775] amdgpu 0000:03:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000B33 [345962.296097] amdgpu 0000:03:00.0: amdgpu: Faulty UTCL2 client ID: CPC (0x5) [345962.296394] amdgpu 0000:03:00.0: amdgpu: MORE_FAULTS: 0x1 [345962.296633] amdgpu 0000:03:00.0: amdgpu: WALKER_ERROR: 0x1 [345962.296876] amdgpu 0000:03:00.0: amdgpu: PERMISSION_FAULTS: 0x3 [345962.297135] amdgpu 0000:03:00.0: amdgpu: MAPPING_ERROR: 0x1 [345962.297377] amdgpu 0000:03:00.0: amdgpu: RW: 0x0 [345962.297682] amdgpu 0000:03:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:169 vmid:0 pasid:0) Signed-off-by: Prike Liang <[email protected]> Reviewed-by: Jonathan Kim <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Dec 6 11:43:05 2024 +0200 drm/bridge: anx7625: use eld_mutex to protect access to connector->eld [ Upstream commit e72bf423a60afd744d13e40ab2194044a3af5217 ] Reading access to connector->eld can happen at the same time the drm_edid_to_eld() updates the data. Take the newly added eld_mutex in order to protect connector->eld from concurrent access. Reviewed-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hermes Wu <[email protected]> Date: Mon Dec 30 18:51:22 2024 +0800 drm/bridge: it6505: Change definition MAX_HDCP_DOWN_STREAM_COUNT [ Upstream commit 85597bc0d70c287ba41f17d14d3d857a38a3d727 ] A HDCP source device shall support max downstream to 127 devices. Change definition MAX_HDCP_DOWN_STREAM_COUNT to 127 KSVs shall save for DRM blocked devices check. This results in struct it6505 growth by ~0.5 KiB. Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Hermes Wu <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20241230-v7-upstream-v7-4-e0fdd4844703@ite.corp-partner.google.com Signed-off-by: Sasha Levin <[email protected]>
Author: Hermes Wu <[email protected]> Date: Mon Dec 30 18:51:23 2024 +0800 drm/bridge: it6505: fix HDCP Bstatus check [ Upstream commit 0fd2ff47d8c207fa3173661de04bb9e8201c0ad2 ] When HDCP is activated, a DisplayPort source receiving CP_IRQ from the sink shall check Bstatus from DPCD and process the corresponding value Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Hermes Wu <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20241230-v7-upstream-v7-5-e0fdd4844703@ite.corp-partner.google.com Signed-off-by: Sasha Levin <[email protected]>
Author: Hermes Wu <[email protected]> Date: Mon Dec 30 18:51:26 2024 +0800 drm/bridge: it6505: fix HDCP CTS compare V matching [ Upstream commit 0989c02c7a5c887c70afeae80c64d0291624e1a7 ] When HDCP negotiation with a repeater device. Checking SHA V' matching must retry 3 times before restarting HDCP. Signed-off-by: Hermes Wu <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20241230-v7-upstream-v7-8-e0fdd4844703@ite.corp-partner.google.com Signed-off-by: Sasha Levin <[email protected]>
Author: Hermes Wu <[email protected]> Date: Mon Dec 30 18:51:27 2024 +0800 drm/bridge: it6505: fix HDCP CTS KSV list wait timer [ Upstream commit 9f9eef9ec1a2b57d95a86fe81df758e8253a7766 ] HDCP must disabled encryption and restart authentication after waiting KSV for 5s. The original method uses a counter in a waitting loop that may wait much longer than it is supposed to. Use time_after() for KSV wait timeout. Signed-off-by: Hermes Wu <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20241230-v7-upstream-v7-9-e0fdd4844703@ite.corp-partner.google.com Signed-off-by: Sasha Levin <[email protected]>
Author: Hermes Wu <[email protected]> Date: Mon Dec 30 18:51:24 2024 +0800 drm/bridge: it6505: fix HDCP encryption when R0 ready [ Upstream commit 8c01b0bae2f9e58f2fee0e811cb90d8331986554 ] When starting HDCP authentication, HDCP encryption should be enabled when R0'is checked. Change encryption enables time at R0' ready. The hardware HDCP engine trigger is changed and the repeater KSV fails will restart HDCP. Signed-off-by: Hermes Wu <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20241230-v7-upstream-v7-6-e0fdd4844703@ite.corp-partner.google.com Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Dec 6 11:43:06 2024 +0200 drm/bridge: ite-it66121: use eld_mutex to protect access to connector->eld [ Upstream commit 39ead6e02ea7d19b421e9d42299d4293fed3064e ] Reading access to connector->eld can happen at the same time the drm_edid_to_eld() updates the data. Take the newly added eld_mutex in order to protect connector->eld from concurrent access. Reviewed-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Dec 6 11:43:04 2024 +0200 drm/connector: add mutex to protect ELD from concurrent access [ Upstream commit df7c8e3dde37a9d81c0613285b43600f3cc70f34 ] The connector->eld is accessed by the .get_eld() callback. This access can collide with the drm_edid_to_eld() updating the data at the same time. Add drm_connector.eld_mutex to protect the data from concurrenct access. Individual drivers are not updated (to reduce possible issues while applying the patch), maintainers are to find a best suitable way to lock that mutex while accessing the ELD data. Reviewed-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Dec 6 11:43:08 2024 +0200 drm/exynos: hdmi: use eld_mutex to protect access to connector->eld [ Upstream commit 5e8436d334ed7f6785416447c50b42077c6503e0 ] Reading access to connector->eld can happen at the same time the drm_edid_to_eld() updates the data. Take the newly added eld_mutex in order to protect connector->eld from concurrent access. Reviewed-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniele Ceraolo Spurio <[email protected]> Date: Tue Jan 14 16:13:34 2025 -0800 drm/i915/guc: Debug print LRC state entries only if the context is pinned commit 57965269896313e1629a518d3971ad55f599b792 upstream. After the context is unpinned the backing memory can also be unpinned, so any accesses via the lrc_reg_state pointer can end up in unmapped memory. To avoid that, make sure to only access that memory if the context is pinned when printing its info. v2: fix newline alignment Fixes: 28ff6520a34d ("drm/i915/guc: Update GuC debugfs to support new GuC") Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Cc: John Harrison <[email protected]> Cc: Matthew Brost <[email protected]> Cc: <[email protected]> # v5.15+ Reviewed-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 5bea40687c5cf2a33bf04e9110eb2e2b80222ef5) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ville Syrjälä <[email protected]> Date: Wed Dec 18 19:36:47 2024 +0200 drm/i915: Drop 64bpp YUV formats from ICL+ SDR planes commit c7b49506b3ba7a62335e6f666a43f67d5cd9fd1e upstream. I'm seeing underruns with these 64bpp YUV formats on TGL. The weird details: - only happens on pipe B/C/D SDR planes, pipe A SDR planes seem fine, as do all HDR planes - somehow CDCLK related, higher CDCLK allows for bigger plane with these formats without underruns. With 300MHz CDCLK I can only go up to 1200 pixels wide or so, with 650MHz even a 3840 pixel wide plane was OK - ICL and ADL so far appear unaffected So not really sure what's the deal with this, but bspec does state "64-bit formats supported only on the HDR planes" so let's just drop these formats from the SDR planes. We already disallow 64bpp RGB formats. Cc: [email protected] Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Juha-Pekka Heikkila <[email protected]> (cherry picked from commit 35e1aacfe536d6e8d8d440cd7155366da2541ad4) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Brian Geffon <[email protected]> Date: Mon Jan 27 15:43:32 2025 -0500 drm/i915: Fix page cleanup on DMA remap failure commit fa6182c8b13ebfdc70ebdc09161a70dd8131f3b1 upstream. When converting to folios the cleanup path of shmem_get_pages() was missed. When a DMA remap fails and the max segment size is greater than PAGE_SIZE it will attempt to retry the remap with a PAGE_SIZEd segment size. The cleanup code isn't properly using the folio apis and as a result isn't handling compound pages correctly. v2 -> v3: (Ville) Just use shmem_sg_free_table() as-is in the failure path of shmem_get_pages(). shmem_sg_free_table() will clear mapping unevictable but it will be reset when it retries in shmem_sg_alloc_table(). v1 -> v2: (Ville) Fixed locations where we were not clearing mapping unevictable. Cc: [email protected] Cc: Ville Syrjala <[email protected]> Cc: Vidya Srinivas <[email protected]> Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13487 Link: https://lore.kernel.org/lkml/[email protected]/ Fixes: 0b62af28f249 ("i915: convert shmem_sg_free_table() to use a folio_batch") Signed-off-by: Brian Geffon <[email protected]> Suggested-by: Tomasz Figa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jonathan Cavitt <[email protected]> Tested-by: Vidya Srinivas <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> (cherry picked from commit 9e304a18630875352636ad52a3d2af47c3bde824) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Haoxiang Li <[email protected]> Date: Thu Dec 19 17:02:56 2024 +0800 drm/komeda: Add check for komeda_get_layer_fourcc_list() commit 79fc672a092d93a7eac24fe20a571d4efd8fa5a4 upstream. Add check for the return value of komeda_get_layer_fourcc_list() to catch the potential exception. Fixes: 5d51f6c0da1b ("drm/komeda: Add writeback support") Cc: [email protected] Signed-off-by: Haoxiang Li <[email protected]> Acked-by: Liviu Dudau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Liviu Dudau <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Maarten Lankhorst <[email protected]> Date: Thu Jan 16 15:28:24 2025 +0100 drm/modeset: Handle tiled displays in pan_display_atomic. commit f4a9dd57e549a17a7dac1c1defec26abd7e5c2d4 upstream. Tiled displays have a different x/y offset to begin with. Instead of attempting to remember this, just apply a delta instead. This fixes the first tile being duplicated on other tiles when vt switching. Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Maarten Lankhorst <[email protected]> Cc: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Dec 6 11:43:11 2024 +0200 drm/radeon: use eld_mutex to protect access to connector->eld [ Upstream commit b54c14f82428c8a602392d4cae1958a71a578132 ] Reading access to connector->eld can happen at the same time the drm_edid_to_eld() updates the data. Take the newly added eld_mutex in order to protect connector->eld from concurrent access. Reviewed-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Tue Nov 5 14:38:16 2024 +0100 drm/rockchip: cdn-dp: Use drm_connector_helper_hpd_irq_event() commit 666e1960464140cc4bc9203c203097e70b54c95a upstream. The code for detecting and updating the connector status in cdn_dp_pd_event_work() has a number of problems. - It does not aquire the locks to call the detect helper and update the connector status. These are struct drm_mode_config.connection_mutex and struct drm_mode_config.mutex. - It does not use drm_helper_probe_detect(), which helps with the details of locking and detection. - It uses the connector's status field to determine a change to the connector status. The epoch_counter field is the correct one. The field signals a change even if the connector status' value did not change. Replace the code with a call to drm_connector_helper_hpd_irq_event(), which fixes all these problems. Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 81632df69772 ("drm/rockchip: cdn-dp: do not use drm_helper_hpd_irq_event") Cc: Chris Zhong <[email protected]> Cc: Guenter Roeck <[email protected]> Cc: Sandy Huang <[email protected]> Cc: "Heiko Stübner" <[email protected]> Cc: Andy Yan <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: <[email protected]> # v4.11+ Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Dec 6 11:43:12 2024 +0200 drm/sti: hdmi: use eld_mutex to protect access to connector->eld [ Upstream commit e99c0b517bcd53cf61f998a3c4291333401cb391 ] Reading access to connector->eld can happen at the same time the drm_edid_to_eld() updates the data. Take the newly added eld_mutex in order to protect connector->eld from concurrent access. Reviewed-by: Maxime Ripard <[email protected]> Acked-by: Raphael Gallais-Pou <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Dec 6 11:43:13 2024 +0200 drm/vc4: hdmi: use eld_mutex to protect access to connector->eld [ Upstream commit 81a9a93b169a273ccc4a9a1ee56f17e9981d3f98 ] Reading access to connector->eld can happen at the same time the drm_edid_to_eld() updates the data. Take the newly added eld_mutex in order to protect connector->eld from concurrent access. Reviewed-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dongwon Kim <[email protected]> Date: Mon Oct 21 02:08:03 2024 +0300 drm/virtio: New fence for every plane update [ Upstream commit d3c55b8ab6fe5fa2e7ab02efd36d09c39ee5022f ] Having a fence linked to a virtio_gpu_framebuffer in the plane update sequence would cause conflict when several planes referencing the same framebuffer (e.g. Xorg screen covering multi-displays configured for an extended mode) and those planes are updated concurrently. So it is needed to allocate a fence for every plane state instead of the framebuffer. Signed-off-by: Dongwon Kim <[email protected]> [[email protected]: rebase, fix up, edit commit message] Signed-off-by: Dmitry Osipenko <[email protected]> Acked-by: Vivek Kasireddy <[email protected]> Reviewed-by: Rob Clark <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Tue Jan 21 18:11:34 2025 -0700 efi: libstub: Use '-std=gnu11' to fix build with GCC 15 commit 8ba14d9f490aef9fd535c04e9e62e1169eb7a055 upstream. GCC 15 changed the default C standard version to C23, which should not have impacted the kernel because it requests the gnu11 standard via '-std=' in the main Makefile. However, the EFI libstub Makefile uses its own set of KBUILD_CFLAGS for x86 without a '-std=' value (i.e., using the default), resulting in errors from the kernel's definitions of bool, true, and false in stddef.h, which are reserved keywords under C23. ./include/linux/stddef.h:11:9: error: expected identifier before ‘false’ 11 | false = 0, ./include/linux/types.h:35:33: error: two or more data types in declaration specifiers 35 | typedef _Bool bool; Set '-std=gnu11' in the x86 cflags to resolve the error and consistently use the same C standard version for the entire kernel. All other architectures reuse KBUILD_CFLAGS from the rest of the kernel, so this issue is not visible for them. Cc: [email protected] Reported-by: Kostadin Shishmanov <[email protected]> Closes: https://lore.kernel.org/4OAhbllK7x4QJGpZjkYjtBYNLd_2whHx9oFiuZcGwtVR4hIzvduultkgfAIRZI3vQpZylu7Gl929HaYFRGeMEalWCpeMzCIIhLxxRhq4U-Y=@protonmail.com/ Reported-by: Jakub Jelinek <[email protected]> Closes: https://lore.kernel.org/Z4467umXR2PZ0M1H@tucnak/ Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kees Cook <[email protected]> Date: Thu Nov 21 07:07:05 2024 -0800 exec: fix up /proc/pid/comm in the execveat(AT_EMPTY_PATH) case [ Upstream commit 543841d1806029889c2f69f040e88b247aba8e22 ] Zbigniew mentioned at Linux Plumber's that systemd is interested in switching to execveat() for service execution, but can't, because the contents of /proc/pid/comm are the file descriptor which was used, instead of the path to the binary[1]. This makes the output of tools like top and ps useless, especially in a world where most fds are opened CLOEXEC so the number is truly meaningless. When the filename passed in is empty (e.g. with AT_EMPTY_PATH), use the dentry's filename for "comm" instead of using the useless numeral from the synthetic fdpath construction. This way the actual exec machinery is unchanged, but cosmetically the comm looks reasonable to admins investigating things. Instead of adding TASK_COMM_LEN more bytes to bprm, use one of the unused flag bits to indicate that we need to set "comm" from the dentry. Suggested-by: Zbigniew Jędrzejewski-Szmek <[email protected]> Suggested-by: Tycho Andersen <[email protected]> Suggested-by: Al Viro <[email protected]> Suggested-by: Linus Torvalds <[email protected]> Link: https://github.com/uapi-group/kernel-features#set-comm-field-before-exec [1] Reviewed-by: Aleksa Sarai <[email protected]> Tested-by: Zbigniew Jędrzejewski-Szmek <[email protected]> Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Prasad Pandit <[email protected]> Date: Mon Mar 11 16:21:22 2024 +0530 firmware: iscsi_ibft: fix ISCSI_IBFT Kconfig entry [ Upstream commit e1e17a1715982201034024863efbf238bee2bdf9 ] Fix ISCSI_IBFT Kconfig entry, replace tab with a space character. Fixes: 138fe4e0697 ("Firmware: add iSCSI iBFT Support") Signed-off-by: Prasad Pandit <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nam Cao <[email protected]> Date: Thu Jan 2 09:22:56 2025 +0100 fs/proc: do_task_stat: Fix ESP not readable during coredump commit ab251dacfbae28772c897f068a4184f478189ff2 upstream. The field "eip" (instruction pointer) and "esp" (stack pointer) of a task can be read from /proc/PID/stat. These fields can be interesting for coredump. However, these fields were disabled by commit 0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in /proc/PID/stat"), because it is generally unsafe to do so. But it is safe for a coredumping process, and therefore exceptions were made: - for a coredumping thread by commit fd7d56270b52 ("fs/proc: Report eip/esp in /prod/PID/stat for coredumping"). - for all other threads in a coredumping process by commit cb8f381f1613 ("fs/proc/array.c: allow reporting eip/esp for all coredumping threads"). The above two commits check the PF_DUMPCORE flag to determine a coredump thread and the PF_EXITING flag for the other threads. Unfortunately, commit 92307383082d ("coredump: Don't perform any cleanups before dumping core") moved coredump to happen earlier and before PF_EXITING is set. Thus, checking PF_EXITING is no longer the correct way to determine threads in a coredumping process. Instead of PF_EXITING, use PF_POSTCOREDUMP to determine the other threads. Checking of PF_EXITING was added for coredumping, so it probably can now be removed. But it doesn't hurt to keep. Fixes: 92307383082d ("coredump: Don't perform any cleanups before dumping core") Cc: [email protected] Cc: Eric W. Biederman <[email protected]> Acked-by: Oleg Nesterov <[email protected]> Acked-by: Kees Cook <[email protected]> Signed-off-by: Nam Cao <[email protected]> Link: https://lore.kernel.org/r/d89af63d478d6c64cc46a01420b46fd6eb147d6f.1735805772.git.namcao@linutronix.de Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mark Tomlinson <[email protected]> Date: Thu Jun 6 15:31:02 2024 +1200 gpio: pca953x: Improve interrupt support [ Upstream commit d6179f6c6204f9932aed3a7a2100b4a295dfed9d ] The GPIO drivers with latch interrupt support (typically types starting with PCAL) have interrupt status registers to determine which particular inputs have caused an interrupt. Unfortunately there is no atomic operation to read these registers and clear the interrupt. Clearing the interrupt is done by reading the input registers. The code was reading the interrupt status registers, and then reading the input registers. If an input changed between these two events it was lost. The solution in this patch is to revert to the non-latch version of code, i.e. remembering the previous input status, and looking for the changes. This system results in no more I2C transfers, so is no slower. The latch property of the device still means interrupts will still be noticed if the input changes back to its initial state. Fixes: 44896beae605 ("gpio: pca953x: add PCAL9535 interrupt support for Galileo Gen2") Signed-off-by: Mark Tomlinson <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans Verkuil <[email protected]> Date: Wed Jan 29 10:51:48 2025 +0100 gpu: drm_dp_cec: fix broken CEC adapter properties check [ Upstream commit 6daaae5ff7f3b23a2dacc9c387ff3d4f95b67cad ] If the hotplug detect of a display is low for longer than one second (configurable through drm_dp_cec_unregister_delay), then the CEC adapter is unregistered since we assume the display was disconnected. If the HPD went low for less than one second, then we check if the properties of the CEC adapter have changed, since that indicates that we actually switch to new hardware and we have to unregister the old CEC device and register a new one. Unfortunately, the test for changed properties was written poorly, and after a new CEC capability was added to the CEC core code the test always returned true (i.e. the properties had changed). As a result the CEC device was unregistered and re-registered for every HPD toggle. If the CEC remote controller integration was also enabled (CONFIG_MEDIA_CEC_RC was set), then the corresponding input device was also unregistered and re-registered. As a result the input device in /sys would keep incrementing its number, e.g.: /sys/devices/pci0000:00/0000:00:08.1/0000:e7:00.0/rc/rc0/input20 Since short HPD toggles are common, the number could over time get into the thousands. While not a serious issue (i.e. nothing crashes), it is not intended to work that way. This patch changes the test so that it only checks for the single CEC capability that can actually change, and it ignores any other capabilities, so this is now safe as well if new caps are added in the future. With the changed test the bit under #ifndef CONFIG_MEDIA_CEC_RC can be dropped as well, so that's a nice cleanup. Signed-off-by: Hans Verkuil <[email protected]> Reported-by: Farblos <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Fixes: 2c6d1fffa1d9 ("drm: add support for DisplayPort CEC-Tunneling-over-AUX") Tested-by: Farblos <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Heiko Stuebner <[email protected]> Date: Thu Nov 7 12:47:04 2024 +0100 HID: hid-sensor-hub: don't use stale platform-data on remove commit 8a5b38c3fd709e8acd2bfdedf66c25e6af759576 upstream. The hid-sensor-hub creates the individual device structs and transfers them to the created mfd platform-devices via the platform_data in the mfd_cell. Before e651a1da442a ("HID: hid-sensor-hub: Allow parallel synchronous reads") the sensor-hub was managing access centrally, with one "completion" in the hub's data structure, which needed to be finished on removal at the latest. The mentioned commit then moved this central management to each hid sensor device, resulting on a completion in each struct hid_sensor_hub_device. The remove procedure was adapted to go through all sensor devices and finish any pending "completion". What this didn't take into account was, platform_device_add_data() that is used by mfd_add{_hotplug}_devices() does a kmemdup on the submitted platform-data. So the data the platform-device gets is a copy of the original data, meaning that the device worked on a different completion than what sensor_hub_remove() currently wants to access. To fix that, use device_for_each_child() to go through each child-device similar to how mfd_remove_devices() unregisters the devices later and with that get the live platform_data to finalize the correct completion. Fixes: e651a1da442a ("HID: hid-sensor-hub: Allow parallel synchronous reads") Cc: [email protected] Signed-off-by: Heiko Stuebner <[email protected]> Acked-by: Benjamin Tissoires <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> Acked-by: Jiri Kosina <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Even Xu <[email protected]> Date: Thu Dec 26 09:35:27 2024 +0800 HID: Wacom: Add PCI Wacom device support [ Upstream commit c4c123504a65583e3689b3de04a61dc5272e453a ] Add PCI device ID of wacom device into driver support list. Signed-off-by: Even Xu <[email protected]> Tested-by: Tatsunosuke Tobita <[email protected]> Reviewed-by: Ping Cheng <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Randolph Ha <[email protected]> Date: Mon Jan 13 14:52:37 2025 -0500 i2c: Force ELAN06FA touchpad I2C bus freq to 100KHz [ Upstream commit bfd74cd1fbc026f04446e67d6915c7e199c2bffd ] When a 400KHz freq is used on this model of ELAN touchpad in Linux, excessive smoothing (similar to when the touchpad's firmware detects a noisy signal) is sometimes applied. As some devices' (e.g, Lenovo V15 G4) ACPI tables specify a 400KHz frequency for this device and some I2C busses (e.g, Designware I2C) default to a 400KHz freq, force the speed to 100KHz as a workaround. For future investigation: This problem may be related to the default HCNT/LCNT values given by some busses' drivers, because they are not specified in the aforementioned devices' ACPI tables, and because the device works without issues on Windows at what is expected to be a 400KHz frequency. The root cause of the issue is not known. Signed-off-by: Randolph Ha <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Frank Li <[email protected]> Date: Wed Jan 8 17:55:33 2025 -0500 i3c: master: Fix missing 'ret' assignment in set_speed() commit b266e0d4dac00eecdfaf50ec3f708fd0c3b39637 upstream. Fix a probe failure in the i3c master driver that occurs when no i3c devices are connected to the bus. The issue arises in `i3c_master_bus_init()` where the `ret` value is not updated after calling `master->ops->set_speed()`. If no devices are present, `ret` remains set to `I3C_ERROR_M2`, causing the code to incorrectly proceed to `err_bus_cleanup`. Cc: [email protected] Fixes: aef79e189ba2 ("i3c: master: support to adjust first broadcast address speed") Signed-off-by: Frank Li <[email protected]> Reviewed-by: Wolfram Sang <[email protected]> Tested-by: Wolfram Sang <[email protected]> Acked-by: Mukesh Kumar Savaliya <[email protected]> Reviewed-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jiasheng Jiang <[email protected]> Date: Fri Jan 31 01:38:32 2025 +0000 ice: Add check for devm_kzalloc() [ Upstream commit a8aa6a6ddce9b5585f2b74f27f3feea1427fb4e7 ] Add check for the return value of devm_kzalloc() to guarantee the success of allocation. Fixes: 42c2eb6b1f43 ("ice: Implement devlink-rate API") Signed-off-by: Jiasheng Jiang <[email protected]> Reviewed-by: Michal Swiatkowski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maciej Fijalkowski <[email protected]> Date: Thu Jan 23 16:01:16 2025 +0100 ice: put Rx buffers after being done with current frame [ Upstream commit 743bbd93cf29f653fae0e1416a31f03231689911 ] Introduce a new helper ice_put_rx_mbuf() that will go through gathered frags from current frame and will call ice_put_rx_buf() on them. Current logic that was supposed to simplify and optimize the driver where we go through a batch of all buffers processed in current NAPI instance turned out to be broken for jumbo frames and very heavy load that was coming from both multi-thread iperf and nginx/wrk pair between server and client. The delay introduced by approach that we are dropping is simply too big and we need to take the decision regarding page recycling/releasing as quick as we can. While at it, address an error path of ice_add_xdp_frag() - we were missing buffer putting from day 1 there. As a nice side effect we get rid of annoying and repetitive three-liner: xdp->data = NULL; rx_ring->first_desc = ntc; rx_ring->nr_frags = 0; by embedding it within introduced routine. Fixes: 1dc1a7e7f410 ("ice: Centrallize Rx buffer recycling") Reported-and-tested-by: Xu Du <[email protected]> Reviewed-by: Przemek Kitszel <[email protected]> Reviewed-by: Simon Horman <[email protected]> Co-developed-by: Jacob Keller <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Signed-off-by: Maciej Fijalkowski <[email protected]> Tested-by: Chandan Kumar Rout <[email protected]> (A Contingent Worker at Intel) Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Javier Carrasco <[email protected]> Date: Sat Dec 14 23:55:50 2024 +0100 iio: light: as73211: fix channel handling in only-color triggered buffer commit ab09c6cfe01b317f515bcd944668697241a54b9d upstream. The channel index is off by one unit if AS73211_SCAN_MASK_ALL is not set (optimized path for color channel readings), and it must be shifted instead of leaving an empty channel for the temperature when it is off. Once the channel index is fixed, the uninitialized channel must be set to zero to avoid pushing uninitialized data. Add available_scan_masks for all channels and only-color channels to let the IIO core demux and repack the enabled channels. Cc: [email protected] Fixes: 403e5586b52e ("iio: light: as73211: New driver") Tested-by: Christian Eggers <[email protected]> Signed-off-by: Javier Carrasco <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Illia Ostapyshyn <[email protected]> Date: Thu Nov 14 18:39:29 2024 +0100 Input: allocate keycode for phone linking [ Upstream commit 1bebc7869c99d466f819dd2cffaef0edf7d7a035 ] The F11 key on the new Lenovo Thinkpad T14 Gen 5, T16 Gen 3, and P14s Gen 5 laptops includes a symbol showing a smartphone and a laptop chained together. According to the user manual, it starts the Microsoft Phone Link software used to connect to Android/iOS devices and relay messages/calls or sync data. As there are no suitable keycodes for this action, introduce a new one. Signed-off-by: Illia Ostapyshyn <[email protected]> Acked-by: Dmitry Torokhov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jens Axboe <[email protected]> Date: Thu Jan 30 08:40:29 2025 -0700 io_uring/net: don't retry connect operation on EPOLLERR commit 8c8492ca64e79c6e0f433e8c9d2bcbd039ef83d0 upstream. If a socket is shutdown before the connection completes, POLLERR is set in the poll mask. However, connect ignores this as it doesn't know, and attempts the connection again. This may lead to a bogus -ETIMEDOUT result, where it should have noticed the POLLERR and just returned -ECONNRESET instead. Have the poll logic check for whether or not POLLERR is set in the mask, and if so, mark the request as failed. Then connect can appropriately fail the request rather than retry it. Reported-by: Sergey Galas <[email protected]> Cc: [email protected] Link: https://github.com/axboe/liburing/discussions/1335 Fixes: 3fb1bd688172 ("io_uring/net: handle -EINPROGRESS correct for IORING_OP_CONNECT") Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Mon Feb 10 15:21:38 2025 +0000 io_uring/rw: commit provided buffer state on async When we get -EIOCBQUEUED, we need to ensure that the buffer is consumed from the provided buffer ring, which can be done with io_kbuf_recycle() + REQ_F_PARTIAL_IO. Reported-by: Muhammad Ramdhan <[email protected]> Reported-by: Bing-Jhong Billy Jheng <[email protected]> Reported-by: Jacob Soo <[email protected]> Fixes: c7fb19428d67d ("io_uring: add support for ring mapped supplied buffers") Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Mon Feb 10 15:21:37 2025 +0000 io_uring: fix io_req_prep_async with provided buffers io_req_prep_async() can import provided buffers, commit the ring state by giving up on that before, it'll be reimported later if needed. Reported-by: Muhammad Ramdhan <[email protected]> Reported-by: Bing-Jhong Billy Jheng <[email protected]> Reported-by: Jacob Soo <[email protected]> Fixes: c7fb19428d67d ("io_uring: add support for ring mapped supplied buffers") Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Tue Jan 28 00:55:24 2025 +0000 io_uring: fix multishots with selected buffers commit d63b0e8a628e62ca85a0f7915230186bb92f8bb4 upstream. We do io_kbuf_recycle() when arming a poll but every iteration of a multishot can grab more buffers, which is why we need to flush the kbuf ring state before continuing with waiting. Cc: [email protected] Fixes: b3fdea6ecb55c ("io_uring: multishot recv") Reported-by: Muhammad Ramdhan <[email protected]> Reported-by: Bing-Jhong Billy Jheng <[email protected]> Reported-by: Jacob Soo <[email protected]> Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/1bfc9990fe435f1fc6152ca9efeba5eb3e68339c.1738025570.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Richard Acayan <[email protected]> Date: Wed Nov 13 19:47:16 2024 -0500 iommu/arm-smmu-qcom: add sdm670 adreno iommu compatible [ Upstream commit 42314738906380cbd3b6e9caf3ad34e1b2d66035 ] Add the compatible for the separate IOMMU on SDM670 for the Adreno GPU. This IOMMU has the compatible strings: "qcom,sdm670-smmu-v2", "qcom,adreno-smmu", "qcom,smmu-v2" While the SMMU 500 doesn't need an entry for this specific SoC, the SMMU v2 compatible should have its own entry, as the fallback entry in arm-smmu.c handles "qcom,smmu-v2" without per-process page table support unless there is an entry here. This entry can't be the "qcom,adreno-smmu" compatible because dedicated GPU IOMMUs can also be SMMU 500 with different handling. Signed-off-by: Richard Acayan <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Robin Murphy <[email protected]> Date: Thu Dec 5 16:33:57 2024 +0000 iommu/arm-smmu-v3: Clean up more on probe failure [ Upstream commit fcbd621567420b3a2f21f49bbc056de8b273c625 ] kmemleak noticed that the iopf queue allocated deep down within arm_smmu_init_structures() can be leaked by a subsequent error return from arm_smmu_device_probe(). Furthermore, after arm_smmu_device_reset() we will also leave the SMMU enabled with an empty Stream Table, silently blocking all DMA. This proves rather annoying for debugging said probe failure, so let's handle it a bit better by putting the SMMU back into (more or less) the same state as if it hadn't probed at all. Signed-off-by: Robin Murphy <[email protected]> Link: https://lore.kernel.org/r/5137901958471cf67f2fad5c2229f8a8f1ae901a.1733406914.git.robin.murphy@arm.com Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nick Chan <[email protected]> Date: Sun Jan 19 00:31:42 2025 +0800 irqchip/apple-aic: Only handle PMC interrupt as FIQ when configured so commit 698244bbb3bfd32ddf9a0b70a12b1c7d69056497 upstream. The CPU PMU in Apple SoCs can be configured to fire its interrupt in one of several ways, and since Apple A11 one of the methods is FIQ, but the check of the configuration register fails to test explicitely for FIQ mode. It tests whether the IMODE bitfield is zero or not and the PMCRO_IACT bit is set. That results in false positives when the IMODE bitfield is not zero, but does not have the mode PMCR0_IMODE_FIQ. Only handle the PMC interrupt as a FIQ when the CPU PMU has been configured to fire FIQs, i.e. the IMODE bitfield value is PMCR0_IMODE_FIQ and PMCR0_IACT is set. Fixes: c7708816c944 ("irqchip/apple-aic: Wire PMU interrupts") Signed-off-by: Nick Chan <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Thu Oct 17 10:09:22 2024 -0700 kbuild: Move -Wenum-enum-conversion to W=2 commit 8f6629c004b193d23612641c3607e785819e97ab upstream. -Wenum-enum-conversion was strengthened in clang-19 to warn for C, which caused the kernel to move it to W=1 in commit 75b5ab134bb5 ("kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1") because there were numerous instances that would break builds with -Werror. Unfortunately, this is not a full solution, as more and more developers, subsystems, and distributors are building with W=1 as well, so they continue to see the numerous instances of this warning. Since the move to W=1, there have not been many new instances that have appeared through various build reports and the ones that have appeared seem to be following similar existing patterns, suggesting that most instances of this warning will not be real issues. The only alternatives for silencing this warning are adding casts (which is generally seen as an ugly practice) or refactoring the enums to macro defines or a unified enum (which may be undesirable because of type safety in other parts of the code). Move the warning to W=2, where warnings that occur frequently but may be relevant should reside. Cc: [email protected] Fixes: 75b5ab134bb5 ("kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1") Link: https://lore.kernel.org/[email protected]/ Signed-off-by: Nathan Chancellor <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marco Elver <[email protected]> Date: Fri Jan 24 13:01:38 2025 +0100 kfence: skip __GFP_THISNODE allocations on NUMA systems commit e64f81946adf68cd75e2207dd9a51668348a4af8 upstream. On NUMA systems, __GFP_THISNODE indicates that an allocation _must_ be on a particular node, and failure to allocate on the desired node will result in a failed allocation. Skip __GFP_THISNODE allocations if we are running on a NUMA system, since KFENCE can't guarantee which node its pool pages are allocated on. Link: https://lkml.kernel.org/r/[email protected] Fixes: 236e9f153852 ("kfence: skip all GFP_ZONEMASK allocations") Signed-off-by: Marco Elver <[email protected]> Reported-by: Vlastimil Babka <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Chistoph Lameter <[email protected]> Cc: Dmitriy Vyukov <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed Jan 15 09:28:35 2025 +0900 ksmbd: fix integer overflows on 32 bit systems commit aab98e2dbd648510f8f51b83fbf4721206ccae45 upstream. On 32bit systems the addition operations in ipc_msg_alloc() can potentially overflow leading to memory corruption. Add bounds checking using KSMBD_IPC_MAX_PAYLOAD to avoid overflow. Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Cc: [email protected] Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marc Zyngier <[email protected]> Date: Tue Feb 4 11:00:48 2025 +0000 KVM: arm64: timer: Always evaluate the need for a soft timer commit b450dcce93bc2cf6d2bfaf5a0de88a94ebad8f89 upstream. When updating the interrupt state for an emulated timer, we return early and skip the setup of a soft timer that runs in parallel with the guest. While this is OK if we have set the interrupt pending, it is pretty wrong if the guest moved CVAL into the future. In that case, no timer is armed and the guest can wait for a very long time (it will take a full put/load cycle for the situation to resolve). This is specially visible with EDK2 running at EL2, but still using the EL1 virtual timer, which in that case is fully emulated. Any key-press takes ages to be captured, as there is no UART interrupt and EDK2 relies on polling from a timer... The fix is simply to drop the early return. If the timer interrupt is pending, we will still return early, and otherwise arm the soft timer. Fixes: 4d74ecfa6458b ("KVM: arm64: Don't arm a hrtimer for an already pending timer") Cc: [email protected] Tested-by: Dmytro Terletskyi <[email protected]> Reviewed-by: Oliver Upton <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Paolo Bonzini <[email protected]> Date: Sun Jan 12 10:34:44 2025 +0100 KVM: e500: always restore irqs [ Upstream commit 87ecfdbc699cc95fac73291b52650283ddcf929d ] If find_linux_pte fails, IRQs will not be restored. This is unlikely to happen in practice since it would have been reported as hanging hosts, but it should of course be fixed anyway. Cc: [email protected] Reported-by: Sean Christopherson <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Wed Oct 9 08:04:50 2024 -0700 KVM: Explicitly verify target vCPU is online in kvm_get_vcpu() commit 1e7381f3617d14b3c11da80ff5f8a93ab14cfc46 upstream. Explicitly verify the target vCPU is fully online _prior_ to clamping the index in kvm_get_vcpu(). If the index is "bad", the nospec clamping will generate '0', i.e. KVM will return vCPU0 instead of NULL. In practice, the bug is unlikely to cause problems, as it will only come into play if userspace or the guest is buggy or misbehaving, e.g. KVM may send interrupts to vCPU0 instead of dropping them on the floor. However, returning vCPU0 when it shouldn't exist per online_vcpus is problematic now that KVM uses an xarray for the vCPUs array, as KVM needs to insert into the xarray before publishing the vCPU to userspace (see commit c5b077549136 ("KVM: Convert the kvm->vcpus array to a xarray")), i.e. before vCPU creation is guaranteed to succeed. As a result, incorrectly providing access to vCPU0 will trigger a use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu() bails out of vCPU creation due to an error and frees vCPU0. Commit afb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, but in doing so introduced an unsolvable teardown conundrum. Preventing accesses to vCPU0 before it's fully online will allow reverting commit afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race. Fixes: 1d487e9bf8ba ("KVM: fix spectrev1 gadgets") Cc: [email protected] Cc: Will Deacon <[email protected]> Cc: Michal Luczaj <[email protected]> Reviewed-by: Pankaj Gupta <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Thu Oct 10 11:23:54 2024 -0700 KVM: PPC: e500: Mark "struct page" dirty in kvmppc_e500_shadow_map() [ Upstream commit c9be85dabb376299504e0d391d15662c0edf8273 ] Mark the underlying page as dirty in kvmppc_e500_ref_setup()'s sole caller, kvmppc_e500_shadow_map(), which will allow converting e500 to __kvm_faultin_pfn() + kvm_release_faultin_page() without having to do a weird dance between ref_setup() and shadow_map(). Opportunistically drop the redundant kvm_set_pfn_accessed(), as shadow_map() puts the page via kvm_release_pfn_clean(). Signed-off-by: Sean Christopherson <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Message-ID: <[email protected]> Stable-dep-of: 87ecfdbc699c ("KVM: e500: always restore irqs") Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Thu Oct 10 11:23:55 2024 -0700 KVM: PPC: e500: Mark "struct page" pfn accessed before dropping mmu_lock [ Upstream commit 84cf78dcd9d65c45ab73998d4ad50f433d53fb93 ] Mark pages accessed before dropping mmu_lock when faulting in guest memory so that shadow_map() can convert to kvm_release_faultin_page() without tripping its lockdep assertion on mmu_lock being held. Marking pages accessed outside of mmu_lock is ok (not great, but safe), but marking pages _dirty_ outside of mmu_lock can make filesystems unhappy. Signed-off-by: Sean Christopherson <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Message-ID: <[email protected]> Stable-dep-of: 87ecfdbc699c ("KVM: e500: always restore irqs") Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Thu Oct 10 11:23:56 2024 -0700 KVM: PPC: e500: Use __kvm_faultin_pfn() to handle page faults [ Upstream commit 419cfb983ca93e75e905794521afefcfa07988bb ] Convert PPC e500 to use __kvm_faultin_pfn()+kvm_release_faultin_page(), and continue the inexorable march towards the demise of kvm_pfn_to_refcounted_page(). Signed-off-by: Sean Christopherson <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Message-ID: <[email protected]> Stable-dep-of: 87ecfdbc699c ("KVM: e500: always restore irqs") Signed-off-by: Sasha Levin <[email protected]>
Author: David Hildenbrand <[email protected]> Date: Tue Jan 7 16:43:41 2025 +0100 KVM: s390: vsie: fix some corner-cases when grabbing vsie pages commit 5f230f41fdd9e799f43a699348dc572bca7159aa upstream. We try to reuse the same vsie page when re-executing the vsie with a given SCB address. The result is that we use the same shadow SCB -- residing in the vsie page -- and can avoid flushing the TLB when re-running the vsie on a CPU. So, when we allocate a fresh vsie page, or when we reuse a vsie page for a different SCB address -- reusing the shadow SCB in different context -- we set ihcpu=0xffff to trigger the flush. However, after we looked up the SCB address in the radix tree, but before we grabbed the vsie page by raising the refcount to 2, someone could reuse the vsie page for a different SCB address, adjusting page->index and the radix tree. In that case, we would be reusing the vsie page with a wrong page->index. Another corner case is that we might set the SCB address for a vsie page, but fail the insertion into the radix tree. Whoever would reuse that page would remove the corresponding radix tree entry -- which might now be a valid entry pointing at another page, resulting in the wrong vsie page getting removed from the radix tree. Let's handle such races better, by validating that the SCB address of a vsie page didn't change after we grabbed it (not reuse for a different SCB; the alternative would be performing another tree lookup), and by setting the SCB address to invalid until the insertion in the tree succeeded (SCB addresses are aligned to 512, so ULONG_MAX is invalid). These scenarios are rare, the effects a bit unclear, and these issues were only found by code inspection. Let's CC stable to be safe. Fixes: a3508fbe9dc6 ("KVM: s390: vsie: initial support for nested virtualization") Cc: [email protected] Signed-off-by: David Hildenbrand <[email protected]> Reviewed-by: Claudio Imbrenda <[email protected]> Reviewed-by: Christoph Schlameuss <[email protected]> Tested-by: Christoph Schlameuss <[email protected]> Message-ID: <[email protected]> Signed-off-by: Claudio Imbrenda <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Fri Aug 2 13:29:40 2024 -0700 KVM: x86: Make x2APIC ID 100% readonly commit 4b7c3f6d04bd53f2e5b228b6821fb8f5d1ba3071 upstream. Ignore the userspace provided x2APIC ID when fixing up APIC state for KVM_SET_LAPIC, i.e. make the x2APIC fully readonly in KVM. Commit a92e2543d6a8 ("KVM: x86: use hardware-compatible format for APIC ID register"), which added the fixup, didn't intend to allow userspace to modify the x2APIC ID. In fact, that commit is when KVM first started treating the x2APIC ID as readonly, apparently to fix some race: static inline u32 kvm_apic_id(struct kvm_lapic *apic) { - return (kvm_lapic_get_reg(apic, APIC_ID) >> 24) & 0xff; + /* To avoid a race between apic_base and following APIC_ID update when + * switching to x2apic_mode, the x2apic mode returns initial x2apic id. + */ + if (apic_x2apic_mode(apic)) + return apic->vcpu->vcpu_id; + + return kvm_lapic_get_reg(apic, APIC_ID) >> 24; } Furthermore, KVM doesn't support delivering interrupts to vCPUs with a modified x2APIC ID, but KVM *does* return the modified value on a guest RDMSR and for KVM_GET_LAPIC. I.e. no remotely sane setup can actually work with a modified x2APIC ID. Making the x2APIC ID fully readonly fixes a WARN in KVM's optimized map calculation, which expects the LDR to align with the x2APIC ID. WARNING: CPU: 2 PID: 958 at arch/x86/kvm/lapic.c:331 kvm_recalculate_apic_map+0x609/0xa00 [kvm] CPU: 2 PID: 958 Comm: recalc_apic_map Not tainted 6.4.0-rc3-vanilla+ #35 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.2-1-1 04/01/2014 RIP: 0010:kvm_recalculate_apic_map+0x609/0xa00 [kvm] Call Trace: <TASK> kvm_apic_set_state+0x1cf/0x5b0 [kvm] kvm_arch_vcpu_ioctl+0x1806/0x2100 [kvm] kvm_vcpu_ioctl+0x663/0x8a0 [kvm] __x64_sys_ioctl+0xb8/0xf0 do_syscall_64+0x56/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fade8b9dd6f Unfortunately, the WARN can still trigger for other CPUs than the current one by racing against KVM_SET_LAPIC, so remove it completely. Reported-by: Michal Luczaj <[email protected]> Closes: https://lore.kernel.org/all/[email protected] Reported-by: Haoyu Wu <[email protected]> Closes: https://lore.kernel.org/all/[email protected] Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Message-ID: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: James Houghton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Fri Jul 19 16:51:00 2024 -0700 KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC) commit 73b42dc69be8564d4951a14d00f827929fe5ef79 upstream. Re-introduce the "split" x2APIC ICR storage that KVM used prior to Intel's IPI virtualization support, but only for AMD. While not stated anywhere in the APM, despite stating the ICR is a single 64-bit register, AMD CPUs store the 64-bit ICR as two separate 32-bit values in ICR and ICR2. When IPI virtualization (IPIv on Intel, all AVIC flavors on AMD) is enabled, KVM needs to match CPU behavior as some ICR ICR writes will be handled by the CPU, not by KVM. Add a kvm_x86_ops knob to control the underlying format used by the CPU to store the x2APIC ICR, and tune it to AMD vs. Intel regardless of whether or not x2AVIC is enabled. If KVM is handling all ICR writes, the storage format for x2APIC mode doesn't matter, and having the behavior follow AMD versus Intel will provide better test coverage and ease debugging. Fixes: 4d1d7942e36a ("KVM: SVM: Introduce logic to (de)activate x2AVIC mode") Cc: [email protected] Cc: Maxim Levitsky <[email protected]> Cc: Suravee Suthikulpanit <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> [JH: fixed conflict with vmx_x86_ops reshuffle due to missing commit 5f18c642ff7e2] Signed-off-by: James Houghton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexander Sverdlin <[email protected]> Date: Thu Nov 14 11:13:59 2024 +0100 leds: lp8860: Write full EEPROM, not only half of it commit 0d2e820a86793595e2a776855d04701109e46663 upstream. I struggle to explain dividing an ARRAY_SIZE() by the size of an element once again. As the latter equals to 2, only the half of EEPROM was ever written. Drop the unexplainable division and write full ARRAY_SIZE(). Cc: [email protected] Fixes: 7a8685accb95 ("leds: lp8860: Introduce TI lp8860 4 channel LED driver") Signed-off-by: Alexander Sverdlin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Mon Feb 17 09:40:43 2025 +0100 Linux 6.6.78 Link: https://lore.kernel.org/r/[email protected] Tested-by: SeongJae Park <[email protected]> Tested-by: Florian Fainelli <[email protected]> Tested-by: Mark Brown <[email protected]> Tested-by: Hardik Garg <[email protected]> Tested-by: Peter Schneider <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: Jon Hunter <[email protected]> Tested-by: Harshit Mogalapalli <[email protected]> Tested-By: Achill Gilgenast <[email protected]> Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Miguel Ojeda <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Carlos Llamas <[email protected]> Date: Thu Oct 24 18:36:26 2024 +0000 lockdep: Fix upper limit for LOCKDEP_*_BITS configs [ Upstream commit e638072e61726cae363d48812815197a2a0e097f ] Lockdep has a set of configs used to determine the size of the static arrays that it uses. However, the upper limit that was initially setup for these configs is too high (30 bit shift). This equates to several GiB of static memory for individual symbols. Using such high values leads to linker errors: $ make defconfig $ ./scripts/config -e PROVE_LOCKING --set-val LOCKDEP_BITS 30 $ make olddefconfig all [...] ld: kernel image bigger than KERNEL_IMAGE_SIZE ld: section .bss VMA wraps around address space Adjust the upper limits to the maximum values that avoid these issues. The need for anything more, likely points to a problem elsewhere. Note that LOCKDEP_CHAINS_BITS was intentionally left out as its upper limit had a different symptom and has already been fixed [1]. Reported-by: J. R. Okajima <[email protected]> Closes: https://lore.kernel.org/all/30795.1620913191@jrobl/ [1] Cc: Peter Zijlstra <[email protected]> Cc: Boqun Feng <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Waiman Long <[email protected]> Cc: Will Deacon <[email protected]> Acked-by: Waiman Long <[email protected]> Signed-off-by: Carlos Llamas <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Tiezhu Yang <[email protected]> Date: Sun Jan 26 21:49:59 2025 +0800 LoongArch: Extend the maximum number of watchpoints commit 531936dee53e471a3ec668de3c94ca357f54b7e8 upstream. The maximum number of load/store watchpoints and fetch instruction watchpoints is 14 each according to LoongArch Reference Manual, so extend the maximum number of watchpoints from 8 to 14 for ptrace. By the way, just simply change 8 to 14 for the definition in struct user_watch_state at the beginning, but it may corrupt uapi, then add a new struct user_watch_state_v2 directly. As far as I can tell, the only users for this struct in the userspace are GDB and LLDB, there are no any problems of software compatibility between the application and kernel according to the analysis. The compatibility problem has been considered while developing and testing. When the applications in the userspace get watchpoint state, the length will be specified which is no bigger than the sizeof struct user_watch_state or user_watch_state_v2, the actual length is assigned as the minimal value of the application and kernel in the generic code of ptrace: kernel/ptrace.c: ptrace_regset(): kiov->iov_len = min(kiov->iov_len, (__kernel_size_t) (regset->n * regset->size)); if (req == PTRACE_GETREGSET) return copy_regset_to_user(task, view, regset_no, 0, kiov->iov_len, kiov->iov_base); else return copy_regset_from_user(task, view, regset_no, 0, kiov->iov_len, kiov->iov_base); For example, there are four kind of combinations, all of them work well. (1) "older kernel + older gdb", the actual length is 8+(8+8+4+4)*8=200; (2) "newer kernel + newer gdb", the actual length is 8+(8+8+4+4)*14=344; (3) "older kernel + newer gdb", the actual length is 8+(8+8+4+4)*8=200; (4) "newer kernel + older gdb", the actual length is 8+(8+8+4+4)*8=200. Link: https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints Cc: [email protected] Fixes: 1a69f7a161a7 ("LoongArch: ptrace: Expose hardware breakpoints to debuggers") Reviewed-by: WANG Xuerui <[email protected]> Reviewed-by: Xi Ruoyao <[email protected]> Signed-off-by: Tiezhu Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Tue Jan 7 10:58:56 2025 +0100 m68k: vga: Fix I/O defines commit 53036937a101b5faeaf98e7438555fa854a1a844 upstream. Including m68k's <asm/raw_io.h> in vga.h on nommu platforms results in conflicting defines with io_no.h for various I/O macros from the __raw_read and __raw_write families. An example error is In file included from arch/m68k/include/asm/vga.h:12, from include/video/vga.h:22, from include/linux/vgaarb.h:34, from drivers/video/aperture.c:12: >> arch/m68k/include/asm/raw_io.h:39: warning: "__raw_readb" redefined 39 | #define __raw_readb in_8 | In file included from arch/m68k/include/asm/io.h:6, from include/linux/io.h:13, from include/linux/irq.h:20, from include/asm-generic/hardirq.h:17, from ./arch/m68k/include/generated/asm/hardirq.h:1, from include/linux/hardirq.h:11, from include/linux/interrupt.h:11, from include/linux/trace_recursion.h:5, from include/linux/ftrace.h:10, from include/linux/kprobes.h:28, from include/linux/kgdb.h:19, from include/linux/fb.h:6, from drivers/video/aperture.c:5: arch/m68k/include/asm/io_no.h:16: note: this is the location of the previous definition 16 | #define __raw_readb(addr) \ | Include <asm/io.h>, which avoids raw_io.h on nommu platforms. Also change the defined values of some of the read/write symbols in vga.h to __raw_read/__raw_write as the raw_in/raw_out symbols are not generally available. Signed-off-by: Thomas Zimmermann <[email protected]> Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: 5c3f968712ce ("m68k/video: Create <asm/vga.h>") Cc: Geert Uytterhoeven <[email protected]> Cc: [email protected] Cc: [email protected] Cc: Helge Deller <[email protected]> Cc: [email protected] # v3.5+ Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pekka Pessi <[email protected]> Date: Mon Dec 2 15:35:59 2024 +0530 mailbox: tegra-hsp: Clear mailbox before using message commit 0b7f8328f988178b55ee11d772a6e1238c04d29d upstream. The Tegra RCE (Camera) driver expects the mailbox to be empty before processing the IVC messages. On RT kernel, the threads processing the IVC messages (which are invoked after `mbox_chan_received_data()` is called) may be on a different CPU or running with a higher priority than the HSP interrupt handler thread. This can cause it to act on the message before the mailbox gets cleared in the HSP interrupt handler resulting in a loss of IVC notification. Fix this by clearing the mailbox data register before calling `mbox_chan_received_data()`. Fixes: 8f585d14030d ("mailbox: tegra-hsp: Add tegra_hsp_sm_ops") Fixes: 74c20dd0f892 ("mailbox: tegra-hsp: Add 128-bit shared mailbox support") Cc: [email protected] Signed-off-by: Pekka Pessi <[email protected]> Signed-off-by: Kartik Rajput <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Jassi Brar <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wei Yang <[email protected]> Date: Wed Nov 13 03:16:14 2024 +0000 maple_tree: simplify split calculation commit 4f6a6bed0bfef4b966f076f33eb4f5547226056a upstream. Patch series "simplify split calculation", v3. This patch (of 3): The current calculation for splitting nodes tries to enforce a minimum span on the leaf nodes. This code is complex and never worked correctly to begin with, due to the min value being passed as 0 for all leaves. The calculation should just split the data as equally as possible between the new nodes. Note that b_end will be one more than the data, so the left side is still favoured in the calculation. The current code may also lead to a deficient node by not leaving enough data for the right side of the split. This issue is also addressed with the split calculation change. [[email protected]: rephrase the change log] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: 54a611b60590 ("Maple Tree: add new data structure") Signed-off-by: Wei Yang <[email protected]> Reviewed-by: Liam R. Howlett <[email protected]> Cc: Sidhartha Kumar <[email protected]> Cc: Lorenzo Stoakes <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sakari Ailus <[email protected]> Date: Tue Dec 3 12:23:01 2024 +0200 media: ccs: Clean up parsed CCS static data on parse failure commit da73efa8e675a2b58f1c7ae61201acfe57714bf7 upstream. ccs_data_parse() releases the allocated in-memory data structure when the parser fails, but it does not clean up parsed metadata that is there to help access the actual data. Do that, in order to return the data structure in a sane state. Fixes: a6b396f410b1 ("media: ccs: Add CCS static data parser library") Cc: [email protected] Signed-off-by: Sakari Ailus <[email protected]> Reviewed-by: Mehdi Djait <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sakari Ailus <[email protected]> Date: Tue Dec 3 10:10:23 2024 +0200 media: ccs: Fix CCS static data parsing for large block sizes commit 82b696750f0b60e7513082a10ad42786854f59f8 upstream. The length field of the CCS static data blocks was mishandled, leading to wrong interpretation of the length header for blocks that are 16 kiB in size. Such large blocks are very, very rare and so this wasn't found earlier. As the length is used as part of input validation, the issue has no security implications. Fixes: a6b396f410b1 ("media: ccs: Add CCS static data parser library") Cc: [email protected] Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mehdi Djait <[email protected]> Date: Wed Dec 11 14:30:45 2024 +0100 media: ccs: Fix cleanup order in ccs_probe() commit 6fdbff0f54786e94f0f630ff200ec1d666b1633e upstream. ccs_limits is allocated in ccs_read_all_limits() after the allocation of mdata.backing. Ensure that resources are freed in the reverse order of their allocation by moving out_free_ccs_limits up. Fixes: a11d3d6891f0 ("media: ccs: Read CCS static data from firmware binaries") Cc: [email protected] Signed-off-by: Mehdi Djait <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tomi Valkeinen <[email protected]> Date: Fri Dec 6 10:26:40 2024 +0200 media: i2c: ds90ub960: Fix logging SP & EQ status only for UB9702 commit 42d0ec194aa12e9b97f09a94fe565ba2e5f631a2 upstream. UB9702 does not have SP and EQ registers, but the driver uses them in log_status(). Fix this by separating the SP and EQ related log_status() work into a separate function (for clarity) and calling that function only for UB960. Cc: [email protected] Fixes: afe267f2d368 ("media: i2c: add DS90UB960 driver") Reviewed-by: Jai Luthra <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tomi Valkeinen <[email protected]> Date: Fri Dec 6 10:26:38 2024 +0200 media: i2c: ds90ub960: Fix UB9702 refclk register access commit ba3bdb93947c90f098061de1fb2458e2ca040093 upstream. UB9702 has the refclk freq register at a different offset than UB960, but the code uses the UB960's offset for both chips. Fix this. The refclk freq is only used for a debug print, so there's no functional change here. Cc: [email protected] Fixes: afe267f2d368 ("media: i2c: add DS90UB960 driver") Reviewed-by: Jai Luthra <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tomi Valkeinen <[email protected]> Date: Fri Dec 6 10:26:41 2024 +0200 media: i2c: ds90ub960: Fix UB9702 VC map commit 5dbbd0609b83f6eb72c005e2e5979d0cd25243c8 upstream. The driver uses a static CSI-2 virtual channel mapping where all virtual channels from an RX port are mapped to a virtual channel number matching the RX port number. The UB960 and UB9702 have different registers for the purpose, and the UB9702 version is not correct. Each of the VC_ID_MAP registers do not contain a single mapping, as the driver currently thinks, but two. This can cause received VCs other than 0 to be mapped in a wrong way. Fix this by writing both mappings to each register. Cc: [email protected] Fixes: afe267f2d368 ("media: i2c: add DS90UB960 driver") Reviewed-by: Jai Luthra <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tomi Valkeinen <[email protected]> Date: Fri Dec 6 10:26:39 2024 +0200 media: i2c: ds90ub960: Fix use of non-existing registers on UB9702 commit 698cf6df87ffa83f259703e7443c15a4c5ceae86 upstream. UB9702 doesn't have the registers for SP and EQ. Adjust the code in ub960_rxport_wait_locks() to not use those registers for UB9702. As these values are only used for a debug print here, there's no functional change. Cc: [email protected] Fixes: afe267f2d368 ("media: i2c: add DS90UB960 driver") Reviewed-by: Jai Luthra <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tomi Valkeinen <[email protected]> Date: Fri Dec 6 10:26:37 2024 +0200 media: i2c: ds90ub9x3: Fix extra fwnode_handle_put() commit 60b45ece41c5632a3a3274115a401cb244180646 upstream. The ub913 and ub953 drivers call fwnode_handle_put(priv->sd.fwnode) as part of their remove process, and if the driver is removed multiple times, eventually leads to put "overflow", possibly causing memory corruption or crash. The fwnode_handle_put() is a leftover from commit 905f88ccebb1 ("media: i2c: ds90ub9x3: Fix sub-device matching"), which changed the code related to the sd.fwnode, but missed removing these fwnode_handle_put() calls. Cc: [email protected] Fixes: 905f88ccebb1 ("media: i2c: ds90ub9x3: Fix sub-device matching") Reviewed-by: Jai Luthra <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Naushir Patuck <[email protected]> Date: Fri Nov 15 20:07:17 2024 +0200 media: imx296: Add standby delay during probe commit 57d10bcac67707caaa542e09dee86e13ea85defc upstream. Add a 2-5ms delay when coming out of standby and before reading the sensor info register durning probe, as instructed by the datasheet. This standby delay is already present when the sensor starts streaming. During a cold-boot, reading the IMX296_SENSOR_INFO register would often return a value of 0x0000, if this delay is not present before. Fixes: cb33db2b6ccf ("media: i2c: IMX296 camera sensor driver") Cc: [email protected] Tested-by: Alexandru Ardelean <[email protected]> Signed-off-by: Naushir Patuck <[email protected]> Reviewed-by: Kieran Bingham <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cosmin Tanislav <[email protected]> Date: Fri Nov 22 16:55:24 2024 +0200 media: mc: fix endpoint iteration commit fb2bd86270cd0ad004f4c614ba4f8c63a5720e25 upstream. When creating links from a subdev to a sink, the current logic tries to iterate over the endpoints of dev's fwnode. This might not be correct when the subdev uses a different fwnode compared to the dev's fwnode. If, when registering, the subdev's fwnode is not set, the code inside v4l2_async_register_subdev will set it to the dev's fwnode. To fix this, just use the subdev's fwnode. Signed-off-by: Cosmin Tanislav <[email protected]> Fixes: 0d3c81e82da9 ("media: v4l2-mc: add v4l2_create_fwnode_links helpers") Cc: [email protected] Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lubomir Rintel <[email protected]> Date: Tue Dec 31 20:04:34 2024 +0100 media: mmp: Bring back registration of the device commit fbb5298bf1a7b71723cd2bb193642429ceb0fb84 upstream. In commit 4af65141e38e ("media: marvell: cafe: Register V4L2 device earlier"), a call to v4l2_device_register() was moved away from mccic_register() into its caller, marvell/cafe's cafe_pci_probe(). This is not the only caller though -- there's also marvell/mmp. Add v4l2_device_register() into mmpcam_probe() to unbreak the MMP camera driver, in a fashion analogous to what's been done to the Cafe driver. Same for the teardown path. Fixes: 4af65141e38e ("media: marvell: cafe: Register V4L2 device earlier") Signed-off-by: Lubomir Rintel <[email protected]> Cc: [email protected] # v6.6+ Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sam Bobrowicz <[email protected]> Date: Fri Nov 22 09:28:01 2024 +0100 media: ov5640: fix get_light_freq on auto commit 001d3753538d26ddcbef011f5643cfff58a7f672 upstream. Light frequency was not properly returned when in auto mode and the detected frequency was 60Hz. Fixes: 19a81c1426c1 ("[media] add Omnivision OV5640 sensor driver") Cc: [email protected] Signed-off-by: Sam Bobrowicz <[email protected]> Signed-off-by: Michal Simek <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ricardo Ribalda <[email protected]> Date: Wed Nov 6 20:36:07 2024 +0000 media: uvcvideo: Fix crash during unbind if gpio unit is in use commit a9ea1a3d88b7947ce8cadb2afceee7a54872bbc5 upstream. We used the wrong device for the device managed functions. We used the usb device, when we should be using the interface device. If we unbind the driver from the usb interface, the cleanup functions are never called. In our case, the IRQ is never disabled. If an IRQ is triggered, it will try to access memory sections that are already free, causing an OOPS. We cannot use the function devm_request_threaded_irq here. The devm_* clean functions may be called after the main structure is released by uvc_delete. Luckily this bug has small impact, as it is only affected by devices with gpio units and the user has to unbind the device, a disconnect will not trigger this error. Cc: [email protected] Fixes: 2886477ff987 ("media: uvcvideo: Implement UVC_EXT_GPIO_UNIT") Reviewed-by: Sergey Senozhatsky <[email protected]> Signed-off-by: Ricardo Ribalda <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ricardo Ribalda <[email protected]> Date: Thu Nov 14 19:10:30 2024 +0000 media: uvcvideo: Fix event flags in uvc_ctrl_send_events commit c31cffd5ae2c3d7ef21d9008977a9d117ce7a64e upstream. If there is an event that needs the V4L2_EVENT_CTRL_CH_FLAGS flag, all the following events will have that flag, regardless if they need it or not. This is because we keep using the same variable all the time and we do not reset its original value. Cc: [email protected] Fixes: 805e9b4a06bf ("[media] uvcvideo: Send control change events for slave ctrls when the master changes") Signed-off-by: Ricardo Ribalda <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ricardo Ribalda <[email protected]> Date: Tue Dec 3 21:20:09 2024 +0000 media: uvcvideo: Remove redundant NULL assignment commit 04d3398f66d2d31c4b8caea88f051a4257b7a161 upstream. ctrl->handle will only be different than NULL for controls that have mappings. This is because that assignment is only done inside uvc_ctrl_set() for mapped controls. Cc: [email protected] Fixes: e5225c820c05 ("media: uvcvideo: Send a control event when a Control Change interrupt arrives") Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Ricardo Ribalda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ricardo Ribalda <[email protected]> Date: Thu Nov 28 20:53:41 2024 +0000 media: uvcvideo: Support partial control reads commit f00ee2ca8da25ebccb8e19956d853c9055e2c8d0 upstream. Some cameras, like the ELMO MX-P3, do not return all the bytes requested from a control if it can fit in less bytes. Eg: Returning 0xab instead of 0x00ab. usb 3-9: Failed to query (GET_DEF) UVC control 3 on unit 2: 1 (exp. 2). Extend the returned value from the camera and return it. Cc: [email protected] Fixes: a763b9fb58be ("media: uvcvideo: Do not return positive errors in uvc_query_ctrl()") Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Ricardo Ribalda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hans de Goede <[email protected]> Date: Thu Nov 14 20:38:08 2024 +0100 mfd: lpc_ich: Add another Gemini Lake ISA bridge PCI device-id [ Upstream commit 1e89d21f8189d286f80b900e1b7cf57cb1f3037e ] On N4100 / N4120 Gemini Lake SoCs the ISA bridge PCI device-id is 31e8 rather the 3197 found on e.g. the N4000 / N4020. While at fix the existing GLK PCI-id table entry breaking the table being sorted by device-id. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mateusz Jończyk <[email protected]> Date: Sun Jan 5 22:18:06 2025 +0100 mips/math-emu: fix emulation of the prefx instruction commit 42a39e4aa59a10aa4afdc14194f3ee63d2db94e1 upstream. Currently, installation of Debian 12.8 for mipsel fails on machines without an FPU [1]. This is caused by the fact that zstd (which is used for initramfs compression) executes the prefx instruction, which is not emulated properly by the kernel. The prefx (Prefetch Indexed) instruction fetches data from memory into the cache without any side effects. Though functionally unrelated, it requires an FPU [2]. Bytecode format of this instruction ends on "001111" binary: (prefx instruction format) & 0x0000003f = 0x0000000f The code in fpux_emu() runs like so: #define MIPSInst(x) x #define MIPSInst_FMA_FFMT(x) (MIPSInst(x) & 0x00000007) #define MIPSInst_FUNC(x) (MIPSInst(x) & 0x0000003f) enum cop1x_func { ..., pfetch_op = 0x0f, ... }; ... switch (MIPSInst_FMA_FFMT(ir)) { ... case 0x3: if (MIPSInst_FUNC(ir) != pfetch_op) return SIGILL; /* ignore prefx operation */ break; default: return SIGILL; } That snippet above contains a logic error and the if (MIPSInst_FUNC(ir) != pfetch_op) comparison always fires. When MIPSInst_FUNC(ir) is equal to pfetch_op, ir must end on 001111 binary. In this case, MIPSInst_FMA_FFMT(ir) must be equal to 0x7, which does not match that case label. This causes emulation failure for the prefx instruction. Fix it. This has been broken by commit 919af8b96c89 ("MIPS: Make definitions of MIPSInst_FMA_{FUNC,FMTM} consistent with MIPS64 manual") which modified the MIPSInst_FMA_FFMT macro without updating the users. Signed-off-by: Mateusz Jończyk <[email protected]> Cc: [email protected] # after 3 weeks Cc: Dengcheng Zhu <[email protected]> Cc: Thomas Bogendoerfer <[email protected]> Cc: Ming Wang <[email protected]> Cc: Tiezhu Yang <[email protected]> Fixes: 919af8b96c89 ("MIPS: Make definitions of MIPSInst_FMA_{FUNC,FMTM} consistent with MIPS64 manual") Signed-off-by: Greg Kroah-Hartman <[email protected]> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091858 [2] MIPS Architecture For Programmers Volume II-A: The MIPS32 Instruction Set Signed-off-by: Thomas Bogendoerfer <[email protected]>
Author: WangYuli <[email protected]> Date: Sat Jan 4 22:47:08 2025 +0800 MIPS: ftrace: Declare ftrace_get_parent_ra_addr() as static commit ddd068d81445b17ac0bed084dfeb9e58b4df3ddd upstream. Declare ftrace_get_parent_ra_addr() as static to suppress clang compiler warning that 'no previous prototype'. This function is not intended to be called from other parts. Fix follow error with clang-19: arch/mips/kernel/ftrace.c:251:15: error: no previous prototype for function 'ftrace_get_parent_ra_addr' [-Werror,-Wmissing-prototypes] 251 | unsigned long ftrace_get_parent_ra_addr(unsigned long self_ra, unsigned long | ^ arch/mips/kernel/ftrace.c:251:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 251 | unsigned long ftrace_get_parent_ra_addr(unsigned long self_ra, unsigned long | ^ | static 1 error generated. Signed-off-by: WangYuli <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kexy Biscuit <[email protected]> Date: Sat Jan 11 01:22:08 2025 +0800 MIPS: Loongson64: remove ROM Size unit in boardinfo commit bd2212d658d7659b9d83c7e2f3a06789d4db1e90 upstream. Per Appendix A.7 in Q/LS 0013-2014 (龙芯CPU开发系统固件与内核接口规范 V2.2, lit. Loongson DevSys Firmware Kernel Interface Specification V2.2), interface_info.size is size of this interface, not size of the LEFI BIOS ROM. In any case, the BIOS ROM Size just cannot be several kilobytes (KB) on Loongson64 LEFI platforms. Reported-by: Mingcong Bai <[email protected]> Suggested-by: Icenowy Zheng <[email protected]> Fixes: 6c1bfbd9df8c ("MIPS: Loongson64: Add /sys/firmware/lefi/boardinfo") Cc: [email protected] Signed-off-by: Kexy Biscuit <[email protected]> Acked-by: Jiaxun Yang <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Anandu Krishnan E <[email protected]> Date: Fri Jan 10 13:42:37 2025 +0000 misc: fastrpc: Deregister device nodes properly in error scenarios commit 637c20002dc8c347001292664055bfbf56544ec6 upstream. During fastrpc_rpmsg_probe, if secure device node registration succeeds but non-secure device node registration fails, the secure device node deregister is not called during error cleanup. Add proper exit paths to ensure proper cleanup in case of error. Fixes: 3abe3ab3cdab ("misc: fastrpc: add secure domain support") Cc: [email protected] Signed-off-by: Anandu Krishnan E <[email protected]> Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ekansh Gupta <[email protected]> Date: Fri Jan 10 13:42:39 2025 +0000 misc: fastrpc: Fix copy buffer page size commit e966eae72762ecfdbdb82627e2cda48845b9dd66 upstream. For non-registered buffer, fastrpc driver copies the buffer and pass it to the remote subsystem. There is a problem with current implementation of page size calculation which is not considering the offset in the calculation. This might lead to passing of improper and out-of-bounds page size which could result in memory issue. Calculate page start and page end using the offset adjusted address instead of absolute address. Fixes: 02b45b47fbe8 ("misc: fastrpc: fix remote page size calculation") Cc: [email protected] Signed-off-by: Ekansh Gupta <[email protected]> Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ekansh Gupta <[email protected]> Date: Fri Jan 10 13:42:38 2025 +0000 misc: fastrpc: Fix registered buffer page address commit 6ca4ea1f88a06a04ed7b2c9c6bf9f00833b68214 upstream. For registered buffers, fastrpc driver sends the buffer information to remote subsystem. There is a problem with current implementation where the page address is being sent with an offset leading to improper buffer address on DSP. This is leads to functional failures as DSP expects base address in page information and extracts offset information from remote arguments. Mask the offset and pass the base page address to DSP. This issue is observed is a corner case when some buffer which is registered with fastrpc framework is passed with some offset by user and then the DSP implementation tried to read the data. As DSP expects base address and takes care of offsetting with remote arguments, passing an offsetted address will result in some unexpected data read in DSP. All generic usecases usually pass the buffer as it is hence is problem is not usually observed. If someone tries to pass offsetted buffer and then tries to compare data at HLOS and DSP end, then the ambiguity will be observed. Fixes: 80f3afd72bd4 ("misc: fastrpc: consider address offset before sending to DSP") Cc: [email protected] Signed-off-by: Ekansh Gupta <[email protected]> Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Vimal Agrawal <[email protected]> Date: Mon Oct 21 13:38:12 2024 +0000 misc: misc_minor_alloc to use ida for all dynamic/misc dynamic minors commit 6d04d2b554b14ae6c428a9c60b6c85f1e5c89f68 upstream. misc_minor_alloc was allocating id using ida for minor only in case of MISC_DYNAMIC_MINOR but misc_minor_free was always freeing ids using ida_free causing a mismatch and following warn: > > WARNING: CPU: 0 PID: 159 at lib/idr.c:525 ida_free+0x3e0/0x41f > > ida_free called for id=127 which is not allocated. > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ... > > [<60941eb4>] ida_free+0x3e0/0x41f > > [<605ac993>] misc_minor_free+0x3e/0xbc > > [<605acb82>] misc_deregister+0x171/0x1b3 misc_minor_alloc is changed to allocate id from ida for all minors falling in the range of dynamic/ misc dynamic minors Fixes: ab760791c0cf ("char: misc: Increase the maximum number of dynamic misc devices to 1048448") Signed-off-by: Vimal Agrawal <[email protected]> Reviewed-by: Dirk VanDerMerwe <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Catalin Marinas <[email protected]> Date: Mon Jan 27 18:42:33 2025 +0000 mm: kmemleak: fix upper boundary check for physical address objects commit 488b5b9eca68497b533ced059be5eff19578bbca upstream. Memblock allocations are registered by kmemleak separately, based on their physical address. During the scanning stage, it checks whether an object is within the min_low_pfn and max_low_pfn boundaries and ignores it otherwise. With the recent addition of __percpu pointer leak detection (commit 6c99d4eb7c5e ("kmemleak: enable tracking for percpu pointers")), kmemleak started reporting leaks in setup_zone_pageset() and setup_per_cpu_pageset(). These were caused by the node_data[0] object (initialised in alloc_node_data()) ending on the PFN_PHYS(max_low_pfn) boundary. The non-strict upper boundary check introduced by commit 84c326299191 ("mm: kmemleak: check physical address when scan") causes the pg_data_t object to be ignored (not scanned) and the __percpu pointers it contains to be reported as leaks. Make the max_low_pfn upper boundary check strict when deciding whether to ignore a physical address object and not scan it. Link: https://lkml.kernel.org/r/[email protected] Fixes: 84c326299191 ("mm: kmemleak: check physical address when scan") Signed-off-by: Catalin Marinas <[email protected]> Reported-by: Jakub Kicinski <[email protected]> Tested-by: Matthieu Baerts (NGI0) <[email protected]> Cc: Patrick Wang <[email protected]> Cc: <[email protected]> [6.0.x] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Shawn Lin <[email protected]> Date: Fri Nov 22 17:37:22 2024 +0800 mmc: core: Respect quirk_max_rate for non-UHS SDIO card [ Upstream commit a2a44f8da29352f76c99c6904ee652911b8dc7dd ] The card-quirk was added to limit the clock-rate for a card with UHS-mode support, although let's respect the quirk for non-UHS mode too, to make the behaviour consistent. Signed-off-by: Shawn Lin <[email protected]> Message-ID: <[email protected]> Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yuanjie Yang <[email protected]> Date: Tue Jan 14 16:35:14 2025 +0800 mmc: sdhci-msm: Correctly set the load for the regulator [ Upstream commit 20a0c37e44063997391430c4ae09973e9cbc3911 ] Qualcomm regulator supports two power supply modes: HPM and LPM. Currently, the sdhci-msm.c driver does not set the load to adjust the current for eMMC and SD. If the regulator dont't set correct load in LPM state, it will lead to the inability to properly initialize eMMC and SD. Set the correct regulator current for eMMC and SD to ensure that the device can work normally even when the regulator is in LPM. Signed-off-by: Yuanjie Yang <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Sun Feb 9 18:41:55 2025 +0100 mptcp: pm: only set fullmesh for subflow endp commit 1bb0d1348546ad059f55c93def34e67cb2a034a6 upstream. With the in-kernel path-manager, it is possible to change the 'fullmesh' flag. The code in mptcp_pm_nl_fullmesh() expects to change it only on 'subflow' endpoints, to recreate more or less subflows using the linked address. Unfortunately, the set_flags() hook was a bit more permissive, and allowed 'implicit' endpoints to get the 'fullmesh' flag while it is not allowed before. That's what syzbot found, triggering the following warning: WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 __mark_subflow_endp_available net/mptcp/pm_netlink.c:1496 [inline] WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_pm_nl_fullmesh net/mptcp/pm_netlink.c:1980 [inline] WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_nl_set_flags net/mptcp/pm_netlink.c:2003 [inline] WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_pm_nl_set_flags+0x974/0xdc0 net/mptcp/pm_netlink.c:2064 Modules linked in: CPU: 0 UID: 0 PID: 6499 Comm: syz.1.413 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_netlink.c:1496 [inline] RIP: 0010:mptcp_pm_nl_fullmesh net/mptcp/pm_netlink.c:1980 [inline] RIP: 0010:mptcp_nl_set_flags net/mptcp/pm_netlink.c:2003 [inline] RIP: 0010:mptcp_pm_nl_set_flags+0x974/0xdc0 net/mptcp/pm_netlink.c:2064 Code: 01 00 00 49 89 c5 e8 fb 45 e8 f5 e9 b8 fc ff ff e8 f1 45 e8 f5 4c 89 f7 be 03 00 00 00 e8 44 1d 0b f9 eb a0 e8 dd 45 e8 f5 90 <0f> 0b 90 e9 17 ff ff ff 89 d9 80 e1 07 38 c1 0f 8c c9 fc ff ff 48 RSP: 0018:ffffc9000d307240 EFLAGS: 00010293 RAX: ffffffff8bb72e03 RBX: 0000000000000000 RCX: ffff88807da88000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000d307430 R08: ffffffff8bb72cf0 R09: 1ffff1100b842a5e R10: dffffc0000000000 R11: ffffed100b842a5f R12: ffff88801e2e5ac0 R13: ffff88805c214800 R14: ffff88805c2152e8 R15: 1ffff1100b842a5d FS: 00005555619f6500(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002840 CR3: 00000000247e6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb14/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2542 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1347 netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1891 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:726 ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583 ___sys_sendmsg net/socket.c:2637 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2669 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5fe8785d29 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff571f5558 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f5fe8975fa0 RCX: 00007f5fe8785d29 RDX: 0000000000000000 RSI: 0000000020000480 RDI: 0000000000000007 RBP: 00007f5fe8801b08 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f5fe8975fa0 R14: 00007f5fe8975fa0 R15: 00000000000011f4 </TASK> Here, syzbot managed to set the 'fullmesh' flag on an 'implicit' and used -- according to 'id_avail_bitmap' -- endpoint, causing the PM to try decrement the local_addr_used counter which is only incremented for the 'subflow' endpoint. Note that 'no type' endpoints -- not 'subflow', 'signal', 'implicit' -- are fine, because their ID will not be marked as used in the 'id_avail' bitmap, and setting 'fullmesh' can help forcing the creation of subflow when receiving an ADD_ADDR. Fixes: 73c762c1f07d ("mptcp: set fullmesh flag in pm_netlink") Cc: [email protected] Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/540 Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> [ Conflicts in pm_netlink.c, because the code has been moved around in commit 6a42477fe449 ("mptcp: update set_flags interfaces"), but the same fix can still be applied at the original place. ] Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Paolo Abeni <[email protected]> Date: Sun Feb 9 18:41:56 2025 +0100 mptcp: prevent excessive coalescing on receive commit 56b824eb49d6258aa0bad09a406ceac3f643cdae upstream. Currently the skb size after coalescing is only limited by the skb layout (the skb must not carry frag_list). A single coalesced skb covering several MSS can potentially fill completely the receive buffer. In such a case, the snd win will zero until the receive buffer will be empty again, affecting tput badly. Fixes: 8268ed4c9d19 ("mptcp: introduce and use mptcp_try_coalesce()") Cc: [email protected] # please delay 2 weeks after 6.13-final release Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ivan Stepchenko <[email protected]> Date: Thu Nov 14 16:29:51 2024 +0300 mtd: onenand: Fix uninitialized retlen in do_otp_read() commit 70a71f8151b9879b0950668ce3ad76263261fee0 upstream. The function do_otp_read() does not set the output parameter *retlen, which is expected to contain the number of bytes actually read. As a result, in onenand_otp_walk(), the tmp_retlen variable remains uninitialized after calling do_otp_walk() and used to change the values of the buf, len and retlen variables. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 49dc08eeda70 ("[MTD] [OneNAND] fix numerous races") Cc: [email protected] Signed-off-by: Ivan Stepchenko <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Vadim Fedorenko <[email protected]> Date: Tue Jan 7 02:48:12 2025 -0800 net/mlx5: use do_aux_work for PHC overflow checks [ Upstream commit e61e6c415ba9ff2b32bb6780ce1b17d1d76238f1 ] The overflow_work is using system wq to do overflow checks and updates for PHC device timecounter, which might be overhelmed by other tasks. But there is dedicated kthread in PTP subsystem designed for such things. This patch changes the work queue to proper align with PTP subsystem and to avoid overloading system work queue. The adjfine() function acts the same way as overflow check worker, we can postpone ptp aux worker till the next overflow period after adjfine() was called. Reviewed-by: Dragos Tatulea <[email protected]> Signed-off-by: Vadim Fedorenko <[email protected]> Acked-by: Tariq Toukan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Delevoryas <[email protected]> Date: Tue Nov 14 10:07:35 2023 -0600 net/ncsi: Add NC-SI 1.2 Get MC MAC Address command [ Upstream commit b8291cf3d1180b5b61299922f17c9441616a805a ] This change adds support for the NC-SI 1.2 Get MC MAC Address command, specified here: https://www.dmtf.org/sites/default/files/standards/documents/DSP0222_1.2.0.pdf It serves the exact same function as the existing OEM Get MAC Address commands, so if a channel reports that it supports NC-SI 1.2, we prefer to use the standard command rather than the OEM command. Verified with an invalid MAC address and 2 valid ones: [ 55.137072] ftgmac100 1e690000.ftgmac eth0: NCSI: Received 3 provisioned MAC addresses [ 55.137614] ftgmac100 1e690000.ftgmac eth0: NCSI: MAC address 0: 00:00:00:00:00:00 [ 55.138026] ftgmac100 1e690000.ftgmac eth0: NCSI: MAC address 1: fa:ce:b0:0c:20:22 [ 55.138528] ftgmac100 1e690000.ftgmac eth0: NCSI: MAC address 2: fa:ce:b0:0c:20:23 [ 55.139241] ftgmac100 1e690000.ftgmac eth0: NCSI: Unable to assign 00:00:00:00:00:00 to device [ 55.140098] ftgmac100 1e690000.ftgmac eth0: NCSI: Set MAC address to fa:ce:b0:0c:20:22 Signed-off-by: Peter Delevoryas <[email protected]> Signed-off-by: Patrick Williams <[email protected]> Signed-off-by: David S. Miller <[email protected]> Stable-dep-of: 9e2bbab94b88 ("net/ncsi: fix locking in Get MAC Address handling") Signed-off-by: Sasha Levin <[email protected]>
Author: Paul Fertser <[email protected]> Date: Thu Jan 9 17:50:54 2025 +0300 net/ncsi: fix locking in Get MAC Address handling [ Upstream commit 9e2bbab94b88295dcc57c7580393c9ee08d7314d ] Obtaining RTNL lock in a response handler is not allowed since it runs in an atomic softirq context. Postpone setting the MAC address by adding a dedicated step to the configuration FSM. Fixes: 790071347a0a ("net/ncsi: change from ndo_set_mac_address to dev_set_mac_address") Cc: [email protected] Link: https://lore.kernel.org/20241129-potin-revert-ncsi-set-mac-addr-v1-1-94ea2cb596af@gmail.com Signed-off-by: Paul Fertser <[email protected]> Tested-by: Potin Lai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Paul Fertser <[email protected]> Date: Mon Jan 20 16:35:36 2025 +0300 net/ncsi: use dev_set_mac_address() for Get MC MAC Address handling commit 05d91cdb1f9108426b14975ef4eeddf15875ca05 upstream. Copy of the rationale from 790071347a0a1a89e618eedcd51c687ea783aeb3: Change ndo_set_mac_address to dev_set_mac_address because dev_set_mac_address provides a way to notify network layer about MAC change. In other case, services may not aware about MAC change and keep using old one which set from network adapter driver. As example, DHCP client from systemd do not update MAC address without notification from net subsystem which leads to the problem with acquiring the right address from DHCP server. Since dev_set_mac_address requires RTNL lock the operation can not be performed directly in the response handler, see 9e2bbab94b88295dcc57c7580393c9ee08d7314d. The way of selecting the first suitable MAC address from the list is changed, instead of having the driver check it this patch just assumes any valid MAC should be good. Fixes: b8291cf3d118 ("net/ncsi: Add NC-SI 1.2 Get MC MAC Address command") Signed-off-by: Paul Fertser <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Paul Fertser <[email protected]> Date: Thu Jan 16 18:29:00 2025 +0300 net/ncsi: wait for the last response to Deselect Package before configuring channel commit 6bb194d036c6e1b329dcdff459338cdd9a54802a upstream. The NCSI state machine as it's currently implemented assumes that transition to the next logical state is performed either explicitly by calling `schedule_work(&ndp->work)` to re-queue itself or implicitly after processing the predefined (ndp->pending_req_num) number of replies. Thus to avoid the configuration FSM from advancing prematurely and getting out of sync with the process it's essential to not skip waiting for a reply. This patch makes the code wait for reception of the Deselect Package response for the last package probed before proceeding to channel configuration. Thanks go to Potin Lai and Cosmo Chou for the initial investigation and testing. Fixes: 8e13f70be05e ("net/ncsi: Probe single packages to avoid conflict") Cc: [email protected] Signed-off-by: Paul Fertser <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jacob Moroni <[email protected]> Date: Mon Feb 3 09:36:05 2025 -0500 net: atlantic: fix warning during hot unplug [ Upstream commit 028676bb189ed6d1b550a0fc570a9d695b6acfd3 ] Firmware deinitialization performs MMIO accesses which are not necessary if the device has already been removed. In some cases, these accesses happen via readx_poll_timeout_atomic which ends up timing out, resulting in a warning at hw_atl2_utils_fw.c:112: [ 104.595913] Call Trace: [ 104.595915] <TASK> [ 104.595918] ? show_regs+0x6c/0x80 [ 104.595923] ? __warn+0x8d/0x150 [ 104.595925] ? aq_a2_fw_deinit+0xcf/0xe0 [atlantic] [ 104.595934] ? report_bug+0x182/0x1b0 [ 104.595938] ? handle_bug+0x6e/0xb0 [ 104.595940] ? exc_invalid_op+0x18/0x80 [ 104.595942] ? asm_exc_invalid_op+0x1b/0x20 [ 104.595944] ? aq_a2_fw_deinit+0xcf/0xe0 [atlantic] [ 104.595952] ? aq_a2_fw_deinit+0xcf/0xe0 [atlantic] [ 104.595959] aq_nic_deinit.part.0+0xbd/0xf0 [atlantic] [ 104.595964] aq_nic_deinit+0x17/0x30 [atlantic] [ 104.595970] aq_ndev_close+0x2b/0x40 [atlantic] [ 104.595975] __dev_close_many+0xad/0x160 [ 104.595978] dev_close_many+0x99/0x170 [ 104.595979] unregister_netdevice_many_notify+0x18b/0xb20 [ 104.595981] ? __call_rcu_common+0xcd/0x700 [ 104.595984] unregister_netdevice_queue+0xc6/0x110 [ 104.595986] unregister_netdev+0x1c/0x30 [ 104.595988] aq_pci_remove+0xb1/0xc0 [atlantic] Fix this by skipping firmware deinitialization altogether if the PCI device is no longer present. Tested with an AQC113 attached via Thunderbolt by performing repeated unplug cycles while traffic was running via iperf. Fixes: 97bde5c4f909 ("net: ethernet: aquantia: Support for NIC-specific code") Signed-off-by: Jacob Moroni <[email protected]> Reviewed-by: Igor Russkikh <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Fainelli <[email protected]> Date: Wed Jan 29 15:13:42 2025 -0800 net: bcmgenet: Correct overlaying of PHY and MAC Wake-on-LAN [ Upstream commit 46ded709232344b5750a852747a8881763c721ab ] Some Wake-on-LAN modes such as WAKE_FILTER may only be supported by the MAC, while others might be only supported by the PHY. Make sure that the .get_wol() returns the union of both rather than only that of the PHY if the PHY supports Wake-on-LAN. When disabling Wake-on-LAN, make sure that this is done at both the PHY and MAC level, rather than doing an early return from the PHY driver. Fixes: 7e400ff35cbe ("net: bcmgenet: Add support for PHY-based Wake-on-LAN") Fixes: 9ee09edc05f2 ("net: bcmgenet: Properly overlay PHY and MAC Wake-on-LAN capabilities") Signed-off-by: Florian Fainelli <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Milos Reljin <[email protected]> Date: Fri Jan 24 10:41:02 2025 +0000 net: phy: c45-tjaxx: add delay between MDIO write and read in soft_reset commit bd1bbab717608757cccbbe08b0d46e6c3ed0ced5 upstream. In application note (AN13663) for TJA1120, on page 30, there's a figure with average PHY startup timing values following software reset. The time it takes for SMI to become operational after software reset ranges roughly from 500 us to 1500 us. This commit adds 2000 us delay after MDIO write which triggers software reset. Without this delay, soft_reset function returns an error and prevents successful PHY init. Cc: [email protected] Fixes: b050f2f15e04 ("phy: nxp-c45: add driver for tja1103") Signed-off-by: Milos Reljin <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://patch.msgid.link/AM8P250MB0124D258E5A71041AF2CC322E1E32@AM8P250MB0124.EURP250.PROD.OUTLOOK.COM Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Mon Feb 3 17:08:38 2025 +0000 net: rose: lock the socket in rose_bind() [ Upstream commit a1300691aed9ee852b0a9192e29e2bdc2411a7e6 ] syzbot reported a soft lockup in rose_loopback_timer(), with a repro calling bind() from multiple threads. rose_bind() must lock the socket to avoid this issue. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/T/#u Signed-off-by: Eric Dumazet <[email protected]> Acked-by: Paolo Abeni <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ido Schimmel <[email protected]> Date: Tue Feb 4 14:38:39 2025 +0200 net: sched: Fix truncation of offloaded action statistics [ Upstream commit 811b8f534fd85e17077bd2ac0413bcd16cc8fb9b ] In case of tc offload, when user space queries the kernel for tc action statistics, tc will query the offloaded statistics from device drivers. Among other statistics, drivers are expected to pass the number of packets that hit the action since the last query as a 64-bit number. Unfortunately, tc treats the number of packets as a 32-bit number, leading to truncation and incorrect statistics when the number of packets since the last query exceeds 0xffffffff: $ tc -s filter show dev swp2 ingress filter protocol all pref 1 flower chain 0 filter protocol all pref 1 flower chain 0 handle 0x1 skip_sw in_hw in_hw_count 1 action order 1: mirred (Egress Redirect to device swp1) stolen index 1 ref 1 bind 1 installed 58 sec used 0 sec Action statistics: Sent 1133877034176 bytes 536959475 pkt (dropped 0, overlimits 0 requeues 0) [...] According to the above, 2111-byte packets were redirected which is impossible as only 64-byte packets were transmitted and the MTU was 1500. Fix by treating packets as a 64-bit number: $ tc -s filter show dev swp2 ingress filter protocol all pref 1 flower chain 0 filter protocol all pref 1 flower chain 0 handle 0x1 skip_sw in_hw in_hw_count 1 action order 1: mirred (Egress Redirect to device swp1) stolen index 1 ref 1 bind 1 installed 61 sec used 0 sec Action statistics: Sent 1370624380864 bytes 21416005951 pkt (dropped 0, overlimits 0 requeues 0) [...] Which shows that only 64-byte packets were redirected (1370624380864 / 21416005951 = 64). Fixes: 380407023526 ("net/sched: Enable netdev drivers to update statistics of offloaded actions") Reported-by: Joe Botha <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Petr Machata <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maciej S. Szmigiero <[email protected]> Date: Thu Jan 9 00:33:50 2025 +0100 net: wwan: iosm: Fix hibernation by re-binding the driver around it [ Upstream commit 0b6f6593aa8c3a05f155c12fd0e7ad33a5149c31 ] Currently, the driver is seriously broken with respect to the hibernation (S4): after image restore the device is back into IPC_MEM_EXEC_STAGE_BOOT (which AFAIK means bootloader stage) and needs full re-launch of the rest of its firmware, but the driver restore handler treats the device as merely sleeping and just sends it a wake-up command. This wake-up command times out but device nodes (/dev/wwan*) remain accessible. However attempting to use them causes the bootloader to crash and enter IPC_MEM_EXEC_STAGE_CD_READY stage (which apparently means "a crash dump is ready"). It seems that the device cannot be re-initialized from this crashed stage without toggling some reset pin (on my test platform that's apparently what the device _RST ACPI method does). While it would theoretically be possible to rewrite the driver to tear down the whole MUX / IPC layers on hibernation (so the bootloader does not crash from improper access) and then re-launch the device on restore this would require significant refactoring of the driver (believe me, I've tried), since there are quite a few assumptions hard-coded in the driver about the device never being partially de-initialized (like channels other than devlink cannot be closed, for example). Probably this would also need some programming guide for this hardware. Considering that the driver seems orphaned [1] and other people are hitting this issue too [2] fix it by simply unbinding the PCI driver before hibernation and re-binding it after restore, much like USB_QUIRK_RESET_RESUME does for USB devices that exhibit a similar problem. Tested on XMM7360 in HP EliteBook 855 G7 both with s2idle (which uses the existing suspend / resume handlers) and S4 (which uses the new code). [1]: https://lore.kernel.org/all/[email protected]/ [2]: https://github.com/xmm7360/xmm7360-pci/issues/211#issuecomment-1804139413 Reviewed-by: Sergey Ryazanov <[email protected]> Signed-off-by: Maciej S. Szmigiero <[email protected]> Link: https://patch.msgid.link/e60287ebdb0ab54c4075071b72568a40a75d0205.1736372610.git.mail@maciej.szmigiero.name Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cong Wang <[email protected]> Date: Mon Feb 3 16:58:40 2025 -0800 netem: Update sch->q.qlen before qdisc_tree_reduce_backlog() [ Upstream commit 638ba5089324796c2ee49af10427459c2de35f71 ] qdisc_tree_reduce_backlog() notifies parent qdisc only if child qdisc becomes empty, therefore we need to reduce the backlog of the child qdisc before calling it. Otherwise it would miss the opportunity to call cops->qlen_notify(), in the case of DRR, it resulted in UAF since DRR uses ->qlen_notify() to maintain its active list. Fixes: f8d4bc455047 ("net/sched: netem: account for backlog updates from child qdisc") Cc: Martin Ottens <[email protected]> Reported-by: Mingi Cho <[email protected]> Signed-off-by: Cong Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Fri Jan 17 12:38:41 2025 +0300 NFC: nci: Add bounds checking in nci_hci_create_pipe() commit 110b43ef05342d5a11284cc8b21582b698b4ef1c upstream. The "pipe" variable is a u8 which comes from the network. If it's more than 127, then it results in memory corruption in the caller, nci_hci_connect_gate(). Cc: [email protected] Fixes: a1b0b9415817 ("NFC: nci: Create pipe on specific gate in nci_hci_connect_gate") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nikita Zhandarovich <[email protected]> Date: Sat Jan 25 07:20:53 2025 +0900 nilfs2: fix possible int overflows in nilfs_fiemap() commit 6438ef381c183444f7f9d1de18f22661cba1e946 upstream. Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result by being prepared to go through potentially maxblocks == INT_MAX blocks, the value in n may experience an overflow caused by left shift of blkbits. While it is extremely unlikely to occur, play it safe and cast right hand expression to wider type to mitigate the issue. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Link: https://lkml.kernel.org/r/[email protected] Fixes: 622daaff0a89 ("nilfs2: fiemap support") Signed-off-by: Nikita Zhandarovich <[email protected]> Signed-off-by: Ryusuke Konishi <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Daniel Wagner <[email protected]> Date: Tue Jan 28 17:34:47 2025 +0100 nvme-fc: use ctrl state getter [ Upstream commit c8ed6cb5d37bc09c7e25e49a670e9fd1a3bd1dfa ] Do not access the state variable directly, instead use proper synchronization so not stale data is read. Fixes: e6e7f7ac03e4 ("nvme: ensure reset state check ordering") Signed-off-by: Daniel Wagner <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Georg Gottleuber <[email protected]> Date: Mon Dec 16 23:28:04 2024 +0100 nvme-pci: Add TUXEDO IBP Gen9 to Samsung sleep quirk commit 11cb3529d18514f7d28ad2190533192aedefd761 upstream. On the TUXEDO InfinityBook Pro Gen9 Intel, a Samsung 990 Evo NVMe leads to a high power consumption in s2idle sleep (4 watts). This patch applies 'Force No Simple Suspend' quirk to achieve a sleep with a lower power consumption, typically around 1.2 watts. Signed-off-by: Georg Gottleuber <[email protected]> Cc: [email protected] Signed-off-by: Werner Sembach <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Georg Gottleuber <[email protected]> Date: Mon Dec 16 23:28:03 2024 +0100 nvme-pci: Add TUXEDO InfinityFlex to Samsung sleep quirk commit dbf2bb1a1319b7c7d8828905378a6696cca6b0f2 upstream. On the TUXEDO InfinityFlex, a Samsung 990 Evo NVMe leads to a high power consumption in s2idle sleep (4 watts). This patch applies 'Force No Simple Suspend' quirk to achieve a sleep with a lower power consumption, typically around 1.4 watts. Signed-off-by: Georg Gottleuber <[email protected]> Cc: [email protected] Signed-off-by: Werner Sembach <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Daniel Wagner <[email protected]> Date: Thu Jan 9 14:30:48 2025 +0100 nvme: handle connectivity loss in nvme_set_queue_count [ Upstream commit 294b2b7516fd06a8dd82e4a6118f318ec521e706 ] When the set feature attempts fails with any NVME status code set in nvme_set_queue_count, the function still report success. Though the numbers of queues set to 0. This is done to support controllers in degraded state (the admin queue is still up and running but no IO queues). Though there is an exception. When nvme_set_features reports an host path error, nvme_set_queue_count should propagate this error as the connectivity is lost, which means also the admin queue is not working anymore. Fixes: 9a0be7abb62f ("nvme: refactor set_queue_count") Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Signed-off-by: Daniel Wagner <[email protected]> Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jennifer Berringer <[email protected]> Date: Mon Dec 30 14:19:01 2024 +0000 nvmem: core: improve range check for nvmem_cell_write() commit 31507fc2ad36e0071751a710449db19c85d82a7f upstream. When __nvmem_cell_entry_write() is called for an nvmem cell that does not need bit shifting, it requires that the len parameter exactly matches the nvmem cell size. However, when the nvmem cell has a nonzero bit_offset, it was skipping this check. Accepting values of len larger than the cell size results in nvmem_cell_prepare_write_buffer() trying to write past the end of a heap buffer that it allocates. Add a check to avoid that problem and instead return -EINVAL when len doesn't match the number of bits expected by the nvmem cell when bit_offset is nonzero. This check uses cell->nbits in order to allow providing the smaller size to cells that are shifted into another byte by bit_offset. For example, a cell with nbits=8 and nonzero bit_offset would have bytes=2 but should accept a 1-byte write here, although no current callers depend on this. Fixes: 69aba7948cbe ("nvmem: Add a simple NVMEM framework for consumers") Cc: [email protected] Signed-off-by: Jennifer Berringer <[email protected]> Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sascha Hauer <[email protected]> Date: Mon Dec 30 14:18:57 2024 +0000 nvmem: imx-ocotp-ele: fix reading from non zero offset commit 3c9e2cb6cecf65f7501004038c5d1ed85fb7db84 upstream. In imx_ocotp_reg_read() the offset comes in as bytes and not as words. This means we have to divide offset by 4 to get to the correct word offset. Also the incoming offset might not be word aligned. In order to read from the OCOTP the driver aligns down the previous word boundary and reads from there. This means we have to skip this alignment offset from the temporary buffer when copying the data to the output buffer. Fixes: 22e9e6fcfb50 ("nvmem: imx: support i.MX93 OCOTP") Signed-off-by: Sascha Hauer <[email protected]> Cc: stable <[email protected]> Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sascha Hauer <[email protected]> Date: Mon Dec 30 14:18:59 2024 +0000 nvmem: imx-ocotp-ele: set word length to 1 commit 1b2cb4d0b5b6a9d9fe78470704309ec75f8a1c3a upstream. The ELE hardware internally has a word length of 4. However, among other things we store MAC addresses in the ELE OCOTP. With a length of 6 bytes these are naturally unaligned to the word length. Therefore we must support unaligned reads in reg_read() and indeed it works properly when reg_read() is called via nvmem_reg_read(). Setting the word size to 4 has the only visible effect that doing unaligned reads from userspace via bin_attr_nvmem_read() do not work because they are rejected by that function. Given that we have to abstract from word accesses to byte accesses in the driver, set the word size to 1. This allows bytewise accesses from userspace to be able to test what the driver has to support anyway. Fixes: 22e9e6fcfb50 ("nvmem: imx: support i.MX93 OCOTP") Signed-off-by: Sascha Hauer <[email protected]> Cc: stable <[email protected]> Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sascha Hauer <[email protected]> Date: Mon Dec 30 14:18:56 2024 +0000 nvmem: imx-ocotp-ele: simplify read beyond device check commit 343aa1e289e8e3dba5e3d054c4eb27da7b4e1ecc upstream. Do the read beyond device check on function entry in bytes instead of 32bit words which is easier to follow. Fixes: 22e9e6fcfb50 ("nvmem: imx: support i.MX93 OCOTP") Signed-off-by: Sascha Hauer <[email protected]> Cc: stable <[email protected]> Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Luca Weiss <[email protected]> Date: Mon Dec 30 14:19:00 2024 +0000 nvmem: qcom-spmi-sdam: Set size in struct nvmem_config commit e88f516ea417c71bb3702603ac6af9e95338cfa6 upstream. Let the nvmem core know what size the SDAM is, most notably this fixes the size of /sys/bus/nvmem/devices/spmi_sdam*/nvmem being '0' and makes user space work with that file. ~ # hexdump -C -s 64 /sys/bus/nvmem/devices/spmi_sdam2/nvmem 00000040 02 01 00 00 04 00 00 00 00 00 00 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000080 Fixes: 40ce9798794f ("nvmem: add QTI SDAM driver") Cc: [email protected] Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: Vladimir Zapolskiy <[email protected]> Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Su Yue <[email protected]> Date: Mon Jan 6 22:06:40 2025 +0800 ocfs2: check dir i_size in ocfs2_find_entry commit b0fce54b8c0d8e5f2b4c243c803c5996e73baee8 upstream. syz reports an out of bounds read: ================================================================== BUG: KASAN: slab-out-of-bounds in ocfs2_match fs/ocfs2/dir.c:334 [inline] BUG: KASAN: slab-out-of-bounds in ocfs2_search_dirblock+0x283/0x6e0 fs/ocfs2/dir.c:367 Read of size 1 at addr ffff88804d8b9982 by task syz-executor.2/14802 CPU: 0 UID: 0 PID: 14802 Comm: syz-executor.2 Not tainted 6.13.0-rc4 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Sched_ext: serialise (enabled+all), task: runnable_at=-10ms Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x229/0x350 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x164/0x530 mm/kasan/report.c:489 kasan_report+0x147/0x180 mm/kasan/report.c:602 ocfs2_match fs/ocfs2/dir.c:334 [inline] ocfs2_search_dirblock+0x283/0x6e0 fs/ocfs2/dir.c:367 ocfs2_find_entry_id fs/ocfs2/dir.c:414 [inline] ocfs2_find_entry+0x1143/0x2db0 fs/ocfs2/dir.c:1078 ocfs2_find_files_on_disk+0x18e/0x530 fs/ocfs2/dir.c:1981 ocfs2_lookup_ino_from_name+0xb6/0x110 fs/ocfs2/dir.c:2003 ocfs2_lookup+0x30a/0xd40 fs/ocfs2/namei.c:122 lookup_open fs/namei.c:3627 [inline] open_last_lookups fs/namei.c:3748 [inline] path_openat+0x145a/0x3870 fs/namei.c:3984 do_filp_open+0xe9/0x1c0 fs/namei.c:4014 do_sys_openat2+0x135/0x1d0 fs/open.c:1402 do_sys_open fs/open.c:1417 [inline] __do_sys_openat fs/open.c:1433 [inline] __se_sys_openat fs/open.c:1428 [inline] __x64_sys_openat+0x15d/0x1c0 fs/open.c:1428 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf6/0x210 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f01076903ad Code: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f01084acfc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 RAX: ffffffffffffffda RBX: 00007f01077cbf80 RCX: 00007f01076903ad RDX: 0000000000105042 RSI: 0000000020000080 RDI: ffffffffffffff9c RBP: 00007f01077cbf80 R08: 0000000000000000 R09: 0000000000000000 R10: 00000000000001ff R11: 0000000000000246 R12: 0000000000000000 R13: 00007f01077cbf80 R14: 00007f010764fc90 R15: 00007f010848d000 </TASK> ================================================================== And a general protection fault in ocfs2_prepare_dir_for_insert: ================================================================== loop0: detected capacity change from 0 to 32768 JBD2: Ignoring recovery information on journal ocfs2: Mounting device (7,0) on (node local, slot 0) with ordered data mode. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 UID: 0 PID: 5096 Comm: syz-executor792 Not tainted 6.11.0-rc4-syzkaller-00002-gb0da640826ba #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:ocfs2_find_dir_space_id fs/ocfs2/dir.c:3406 [inline] RIP: 0010:ocfs2_prepare_dir_for_insert+0x3309/0x5c70 fs/ocfs2/dir.c:4280 Code: 00 00 e8 2a 25 13 fe e9 ba 06 00 00 e8 20 25 13 fe e9 4f 01 00 00 e8 16 25 13 fe 49 8d 7f 08 49 8d 5f 09 48 89 f8 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 bd 23 00 00 48 89 d8 48 c1 e8 03 42 0f RSP: 0018:ffffc9000af9f020 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000009 RCX: ffff88801e27a440 RDX: 0000000000000000 RSI: 0000000000000400 RDI: 0000000000000008 RBP: ffffc9000af9f830 R08: ffffffff8380395b R09: ffffffff838090a7 R10: 0000000000000002 R11: ffff88801e27a440 R12: dffffc0000000000 R13: ffff88803c660878 R14: f700000000000088 R15: 0000000000000000 FS: 000055555a677380(0000) GS:ffff888020800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000560bce569178 CR3: 000000001de5a000 CR4: 0000000000350ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ocfs2_mknod+0xcaf/0x2b40 fs/ocfs2/namei.c:292 vfs_mknod+0x36d/0x3b0 fs/namei.c:4088 do_mknodat+0x3ec/0x5b0 __do_sys_mknodat fs/namei.c:4166 [inline] __se_sys_mknodat fs/namei.c:4163 [inline] __x64_sys_mknodat+0xa7/0xc0 fs/namei.c:4163 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f2dafda3a99 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe336a6658 EFLAGS: 00000246 ORIG_RAX: 0000000000000103 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f2dafda3a99 RDX: 00000000000021c0 RSI: 0000000020000040 RDI: 00000000ffffff9c RBP: 00007f2dafe1b5f0 R08: 0000000000004480 R09: 000055555a6784c0 R10: 0000000000000103 R11: 0000000000000246 R12: 00007ffe336a6680 R13: 00007ffe336a68a8 R14: 431bde82d7b634db R15: 00007f2dafdec03b </TASK> ================================================================== The two reports are all caused invalid negative i_size of dir inode. For ocfs2, dir_inode can't be negative or zero. Here add a check in which is called by ocfs2_check_dir_for_entry(). It fixes the second report as ocfs2_check_dir_for_entry() must be called before ocfs2_prepare_dir_for_insert(). Also set a up limit for dir with OCFS2_INLINE_DATA_FL. The i_size can't be great than blocksize. Link: https://lkml.kernel.org/r/[email protected] Reported-by: Jiacheng Xu <[email protected]> Link: https://lore.kernel.org/ocfs2-devel/[email protected]/T/#u Reported-by: [email protected] Link: https://lore.kernel.org/all/[email protected]/T/ Signed-off-by: Su Yue <[email protected]> Reviewed-by: Heming Zhao <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Jun Piao <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Heming Zhao <[email protected]> Date: Tue Jan 21 19:22:03 2025 +0800 ocfs2: fix incorrect CPU endianness conversion causing mount failure commit f921da2c34692dfec5f72b5ae347b1bea22bb369 upstream. Commit 23aab037106d ("ocfs2: fix UBSAN warning in ocfs2_verify_volume()") introduced a regression bug. The blksz_bits value is already converted to CPU endian in the previous code; therefore, the code shouldn't use le32_to_cpu() anymore. Link: https://lkml.kernel.org/r/[email protected] Fixes: 23aab037106d ("ocfs2: fix UBSAN warning in ocfs2_verify_volume()") Signed-off-by: Heming Zhao <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Jun Piao <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthew Wilcox (Oracle) <[email protected]> Date: Thu Dec 5 17:16:29 2024 +0000 ocfs2: handle a symlink read error correctly commit 2b4c2094da6d84e69b843dd3317902e977bf64bd upstream. Patch series "Convert ocfs2 to use folios". Mark did a conversion of ocfs2 to use folios and sent it to me as a giant patch for review ;-) So I've redone it as individual patches, and credited Mark for the patches where his code is substantially the same. It's not a bad way to do it; his patch had some bugs and my patches had some bugs. Hopefully all our bugs were different from each other. And hopefully Mark likes all the changes I made to his code! This patch (of 23): If we can't read the buffer, be sure to unlock the page before returning. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Jun Piao <[email protected]> Cc: Mark Tinguely <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zijun Hu <[email protected]> Date: Thu Jan 9 21:26:52 2025 +0800 of: Correct child specifier used as input of the 2nd nexus node commit e4c00c9b1f70cd11792ff5b825899a6ee0234a62 upstream. API of_parse_phandle_with_args_map() will use wrong input for nexus node Nexus_2 as shown below: Node_1 Nexus_1 Nexus_2 &Nexus_1,arg_1 -> arg_1,&Nexus_2,arg_2' -> &Nexus_2,arg_2 -> arg_2,... map-pass-thru=<...> Nexus_1's output arg_2 should be used as input of Nexus_2, but the API wrongly uses arg_2' instead which != arg_2 due to Nexus_1's map-pass-thru. Fix by always making @match_array point to @initial_match_array into which to store nexus output. Fixes: bd6f2fd5a1d5 ("of: Support parsing phandle argument lists through a nexus node") Cc: [email protected] Signed-off-by: Zijun Hu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zijun Hu <[email protected]> Date: Mon Dec 16 08:40:40 2024 +0800 of: Fix of_find_node_opts_by_path() handling of alias+path+options commit b9e58c934c56aa35b0fb436d9afd86ef326bae0e upstream. of_find_node_opts_by_path() fails to find OF device node when its @path parameter have pattern below: "alias-name/node-name-1/.../node-name-N:options". The reason is that alias name length calculated by the API is wrong, as explained by example below: "testcase-alias/phandle-tests/consumer-a:testaliasoption". ^ ^ ^ 0 14 39 The right length of alias 'testcase-alias' is 14, but the result worked out by the API is 39 which is obvious wrong. Fix by using index of either '/' or ':' as the length who comes earlier. Fixes: 75c28c09af99 ("of: add optional options parameter to of_find_node_by_path()") Cc: [email protected] Signed-off-by: Zijun Hu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zijun Hu <[email protected]> Date: Thu Jan 9 21:27:00 2025 +0800 of: reserved-memory: Fix using wrong number of cells to get property 'alignment' commit 267b21d0bef8e67dbe6c591c9991444e58237ec9 upstream. According to DT spec, size of property 'alignment' is based on parent node’s #size-cells property. But __reserved_mem_alloc_size() wrongly uses @dt_root_addr_cells to get the property obviously. Fix by using @dt_root_size_cells instead of @dt_root_addr_cells. Fixes: 3f0c82066448 ("drivers: of: add initialization code for dynamic reserved memory") Cc: [email protected] Signed-off-by: Zijun Hu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Werner Sembach <[email protected]> Date: Tue Jan 14 23:23:54 2025 +0100 PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1 commit b1049f2d68693c80a576c4578d96774a68df2bad upstream. commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") sets the policy that all PCIe ports are allowed to use D3. When the system is suspended if the port is not power manageable by the platform and won't be used for wakeup via a PME this sets up the policy for these ports to go into D3hot. This policy generally makes sense from an OSPM perspective but it leads to problems with wakeup from suspend on the TUXEDO Sirius 16 Gen 1 with a specific old BIOS. This manifests as a system hang. On the affected Device + BIOS combination, add a quirk for the root port of the problematic controller to ensure that these root ports are not put into D3hot at suspend. This patch is based on https://lore.kernel.org/linux-pci/[email protected] but with the added condition both in the documentation and in the code to apply only to the TUXEDO Sirius 16 Gen 1 with a specific old BIOS and only the affected root ports. Fixes: 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") Suggested-by: Mario Limonciello <[email protected]> Link: https://lore.kernel.org/r/[email protected] Co-developed-by: Georg Gottleuber <[email protected]> Signed-off-by: Georg Gottleuber <[email protected]> Signed-off-by: Werner Sembach <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Cc: <[email protected]> # 6.1+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zijun Hu <[email protected]> Date: Tue Dec 10 22:00:20 2024 +0800 PCI: endpoint: Finish virtual EP removal in pci_epf_remove_vepf() commit 3b9f942eb21c92041905e3943a8d5177c9a9d89d upstream. When removing a virtual Endpoint, pci_epf_remove_vepf() failed to clear epf_vf->epf_pf, which caused a subsequent pci_epf_add_vepf() to incorrectly return -EBUSY: pci_epf_add_vepf(epf_pf, epf_vf) // add pci_epf_remove_vepf(epf_pf, epf_vf) // remove pci_epf_add_vepf(epf_pf, epf_vf) // add again, -EBUSY error Fix by clearing epf_vf->epf_pf in pci_epf_remove_vepf(). Link: https://lore.kernel.org/r/[email protected] Fixes: 1cf362e907f3 ("PCI: endpoint: Add support to add virtual function in endpoint core") Signed-off-by: Zijun Hu <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Frank Li <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kuan-Wei Chiu <[email protected]> Date: Thu Jan 16 19:08:42 2025 +0800 perf bench: Fix undefined behavior in cmpworker() commit 62892e77b8a64b9dc0e1da75980aa145347b6820 upstream. The comparison function cmpworker() violates the C standard's requirements for qsort() comparison functions, which mandate symmetry and transitivity: Symmetry: If x < y, then y > x. Transitivity: If x < y and y < z, then x < z. In its current implementation, cmpworker() incorrectly returns 0 when w1->tid < w2->tid, which breaks both symmetry and transitivity. This violation causes undefined behavior, potentially leading to issues such as memory corruption in glibc [1]. Fix the issue by returning -1 when w1->tid < w2->tid, ensuring compliance with the C standard and preventing undefined behavior. Link: https://www.qualys.com/2024/01/30/qsort.txt [1] Fixes: 121dd9ea0116 ("perf bench: Add epoll parallel epoll_wait benchmark") Cc: [email protected] Signed-off-by: Kuan-Wei Chiu <[email protected]> Reviewed-by: James Clark <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Javier Carrasco <[email protected]> Date: Wed Nov 6 23:04:39 2024 +0100 pinctrl: samsung: fix fwnode refcount cleanup if platform_get_irq_optional() fails commit 459915f55509f4bfd6076daa1428e28490ddee3b upstream. Commit 50ebd19e3585 ("pinctrl: samsung: drop pin banks references on error paths") fixed the pin bank references on the error paths of the probe function, but there is still an error path where this is not done. If samsung_pinctrl_get_soc_data() does not fail, the child references will have acquired, and they will need to be released in the error path of platform_get_irq_optional(), as it is done in the following error paths within the probe function. Replace the direct return in the error path with a goto instruction to the cleanup function. Cc: [email protected] Fixes: a382d568f144 ("pinctrl: samsung: Use platform_get_irq_optional() to get the interrupt") Signed-off-by: Javier Carrasco <[email protected]> Link: https://lore.kernel.org/r/[email protected] [krzysztof: change Fixes SHA to point to commit introducing the return leading to OF node leak] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Armin Wolf <[email protected]> Date: Sun Jan 19 21:17:22 2025 +0100 platform/x86: acer-wmi: Ignore AC events [ Upstream commit f6bfa25c6665f8721421ea94fe506cc22f1d4b43 ] On the Acer Swift SFG14-41, the events 8 - 1 and 8 - 0 are printed on AC connect/disconnect. Ignore those events to avoid spamming the kernel log with error messages. Reported-by: Farhan Anwar <[email protected]> Closes: https://lore.kernel.org/platform-driver-x86/[email protected] Tested-by: Rayan Margham <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Armin Wolf <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Mon Dec 9 23:05:19 2024 +0100 platform/x86: int3472: Check for adev == NULL [ Upstream commit cd2fd6eab480dfc247b737cf7a3d6b009c4d0f1c ] Not all devices have an ACPI companion fwnode, so adev might be NULL. This can e.g. (theoretically) happen when a user manually binds one of the int3472 drivers to another i2c/platform device through sysfs. Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer(). Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mike Snitzer <[email protected]> Date: Thu Jan 16 20:05:39 2025 -0500 pnfs/flexfiles: retry getting layout segment for reads commit eb3fabde15bccdf34f1c9b35a83aa4c0dacbb4ca upstream. If ff_layout_pg_get_read()'s attempt to get a layout segment results in -EAGAIN have ff_layout_pg_init_read() retry it after sleeping. If "softerr" mount is used, use 'io_maxretrans' to limit the number of attempts to get a layout segment. This fixes a long-standing issue of O_DIRECT reads failing with -EAGAIN (11) when using flexfiles Client Side Mirroring (CSM). Cc: [email protected] Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Narayana Murty N <[email protected]> Date: Thu Jan 16 04:39:54 2025 -0600 powerpc/pseries/eeh: Fix get PE state translation commit 11b93559000c686ad7e5ab0547e76f21cc143844 upstream. The PE Reset State "0" returned by RTAS calls "ibm_read_slot_reset_[state|state2]" indicates that the reset is deactivated and the PE is in a state where MMIO and DMA are allowed. However, the current implementation of "pseries_eeh_get_state()" does not reflect this, causing drivers to incorrectly assume that MMIO and DMA operations cannot be resumed. The userspace drivers as a part of EEH recovery using VFIO ioctls fail to detect when the recovery process is complete. The VFIO_EEH_PE_GET_STATE ioctl does not report the expected EEH_PE_STATE_NORMAL state, preventing userspace drivers from functioning properly on pseries systems. The patch addresses this issue by updating 'pseries_eeh_get_state()' to include "EEH_STATE_MMIO_ENABLED" and "EEH_STATE_DMA_ENABLED" in the result mask for PE Reset State "0". This ensures correct state reporting to the callers, aligning the behavior with the PAPR specification and fixing the bug in EEH recovery for VFIO user workflows. Fixes: 00ba05a12b3c ("powerpc/pseries: Cleanup on pseries_eeh_get_state()") Cc: [email protected] Reviewed-by: Ritesh Harjani (IBM) <[email protected]> Signed-off-by: Narayana Murty N <[email protected]> Link: https://lore.kernel.org/stable/20241212075044.10563-1-nnmlinux%40linux.ibm.com Signed-off-by: Madhavan Srinivasan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kuan-Wei Chiu <[email protected]> Date: Sat Sep 28 19:36:08 2024 +0800 printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX [ Upstream commit 3d6f83df8ff2d5de84b50377e4f0d45e25311c7a ] Shifting 1 << 31 on a 32-bit int causes signed integer overflow, which leads to undefined behavior. To prevent this, cast 1 to u32 before performing the shift, ensuring well-defined behavior. This change explicitly avoids any potential overflow by ensuring that the shift occurs on an unsigned 32-bit integer. Signed-off-by: Kuan-Wei Chiu <[email protected]> Acked-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Weißschuh <[email protected]> Date: Thu Jan 23 08:22:40 2025 +0100 ptp: Ensure info->enable callback is always set commit fd53aa40e65f518453115b6f56183b0c201db26b upstream. The ioctl and sysfs handlers unconditionally call the ->enable callback. Not all drivers implement that callback, leading to NULL dereferences. Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c. Instead use a dummy callback if no better was specified by the driver. Fixes: d94ba80ebbea ("ptp: Added a brand new class driver for ptp clocks.") Cc: [email protected] Signed-off-by: Thomas Weißschuh <[email protected]> Acked-by: Richard Cochran <[email protected]> Reviewed-by: Michal Swiatkowski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Conor Dooley <[email protected]> Date: Wed Jan 22 14:42:56 2025 +0000 pwm: microchip-core: fix incorrect comparison with max period commit 752b6e3af374460a2de18f0c10bfa06bf844dbe8 upstream. In mchp_core_pwm_apply_locked(), if hw_period_steps is equal to its max, an error is reported and .apply fails. The max value is actually a permitted value however, and so this check can fail where multiple channels are enabled. For example, the first channel to be configured requests a period that sets hw_period_steps to the maximum value, and when a second channel is enabled the driver reads hw_period_steps back from the hardware and finds it to be the maximum possible value, triggering the warning on a permitted value. The value to be avoided is 255 (PERIOD_STEPS_MAX + 1), as that will produce undesired behaviour, so test for greater than, rather than equal to. Fixes: 2bf7ecf7b4ff ("pwm: add microchip soft ip corePWM driver") Cc: [email protected] Signed-off-by: Conor Dooley <[email protected]> Link: https://lore.kernel.org/r/20250122-pastor-fancied-0b993da2d2d2@spud Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Koichiro Den <[email protected]> Date: Fri Feb 7 01:21:30 2025 +0900 Revert "btrfs: avoid monopolizing a core when activating a swap file" This reverts commit 6e1a8225930719a9f352d56320214e33e2dde0a6. The backport for linux-6.6.y, commit 6e1a82259307 ("btrfs: avoid monopolizing a core when activating a swap file"), inserted cond_resched() in the wrong location. Revert it now; a subsequent commit will re-backport the original patch. Fixes: 6e1a82259307 ("btrfs: avoid monopolizing a core when activating a swap file") # linux-6.6.y Signed-off-by: Koichiro Den <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tom Chung <[email protected]> Date: Tue Feb 4 15:07:44 2025 +0800 Revert "drm/amd/display: Use HW lock mgr for PSR1" commit f245b400a223a71d6d5f4c72a2cb9b573a7fc2b6 upstream. This reverts commit a2b5a9956269 ("drm/amd/display: Use HW lock mgr for PSR1") Because it may cause system hang while connect with two edp panel. Acked-by: Wayne Lin <[email protected]> Signed-off-by: Tom Chung <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Tue Jan 14 17:00:45 2025 -0300 Revert "media: uvcvideo: Require entities to have a non-zero unique ID" commit 8004d635f27bbccaa5c083c50d4d5302a6ffa00e upstream. This reverts commit 3dd075fe8ebbc6fcbf998f81a75b8c4b159a6195. Tomasz has reported that his device, Generalplus Technology Inc. 808 Camera, with ID 1b3f:2002, stopped being detected: $ ls -l /dev/video* zsh: no matches found: /dev/video* [ 7.230599] usb 3-2: Found multiple Units with ID 5 This particular device is non-compliant, having both the Output Terminal and Processing Unit with ID 5. uvc_scan_fallback, though, is able to build a chain. However, when media elements are added and uvc_mc_create_links call uvc_entity_by_id, it will get the incorrect entity, media_create_pad_link will WARN, and it will fail to register the entities. In order to reinstate support for such devices in a timely fashion, reverting the fix for these warnings is appropriate. A proper fix that considers the existence of such non-compliant devices will be submitted in a later development cycle. Reported-by: Tomasz Sikora <[email protected]> Fixes: 3dd075fe8ebb ("media: uvcvideo: Require entities to have a non-zero unique ID") Cc: [email protected] Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Reviewed-by: Ricardo Ribalda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michal Simek <[email protected]> Date: Wed Nov 27 17:01:22 2024 +0100 rtc: zynqmp: Fix optional clock name property commit 2a388ff22d2cbfc5cbd628ef085bdcd3b7dc64f5 upstream. Clock description in DT binding introduced by commit f69060c14431 ("dt-bindings: rtc: zynqmp: Add clock information") is talking about "rtc" clock name but driver is checking "rtc_clk" name instead. Because clock is optional property likely in was never handled properly by the driver. Fixes: 07dcc6f9c762 ("rtc: zynqmp: Add calibration set and get support") Signed-off-by: Michal Simek <[email protected]> Cc: [email protected] Reviewed-by: Peter Korsgaard <[email protected]> Link: https://lore.kernel.org/r/cd5f0c9d01ec1f5a240e37a7e0d85b8dacb3a869.1732723280.git.michal.simek@amd.com Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tomas Glozar <[email protected]> Date: Tue Jan 7 15:48:21 2025 +0100 rtla/osnoise: Distinguish missing workload option commit 80d3ba1cf51bfbbb3b098434f2b2c95cd7c0ae5c upstream. osnoise_set_workload returns -1 for both missing OSNOISE_WORKLOAD option and failure in setting the option. Return -1 for missing and -2 for failure to distinguish them. Cc: [email protected] Cc: John Kacur <[email protected]> Cc: Luis Goncalves <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Tomas Glozar <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tomas Glozar <[email protected]> Date: Tue Jan 7 15:48:22 2025 +0100 rtla/timerlat_hist: Set OSNOISE_WORKLOAD for kernel threads commit d8d866171a414ed88bd0d720864095fd75461134 upstream. When using rtla timerlat with userspace threads (-u or -U), rtla disables the OSNOISE_WORKLOAD option in /sys/kernel/tracing/osnoise/options. This option is not re-enabled in a subsequent run with kernel-space threads, leading to rtla collecting no results if the previous run exited abnormally: $ rtla timerlat hist -u ^\Quit (core dumped) $ rtla timerlat hist -k -d 1s Index over: count: min: avg: max: ALL: IRQ Thr Usr count: 0 0 0 min: - - - avg: - - - max: - - - The issue persists until OSNOISE_WORKLOAD is set manually by running: $ echo OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options Set OSNOISE_WORKLOAD when running rtla with kernel-space threads if available to fix the issue. Cc: [email protected] Cc: John Kacur <[email protected]> Cc: Luis Goncalves <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: ed774f7481fa ("rtla/timerlat_hist: Add timerlat user-space support") Signed-off-by: Tomas Glozar <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tomas Glozar <[email protected]> Date: Thu Jan 16 15:49:28 2025 +0100 rtla/timerlat_hist: Stop timerlat tracer on signal commit c73cab9dbed04d8f65ca69177b4b21ed3e09dfa7 upstream. Currently, when either SIGINT from the user or SIGALRM from the duration timer is caught by rtla-timerlat, stop_tracing is set to break out of the main loop. This is not sufficient for cases where the timerlat tracer is producing more data than rtla can consume, since in that case, rtla is looping indefinitely inside tracefs_iterate_raw_events, never reaches the check of stop_tracing and hangs. In addition to setting stop_tracing, also stop the timerlat tracer on received signal (SIGINT or SIGALRM). This will stop new samples so that the existing samples may be processed and tracefs_iterate_raw_events eventually exits. Cc: [email protected] Cc: John Kacur <[email protected]> Cc: Luis Goncalves <[email protected]> Cc: Gabriele Monaco <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: 1eeb6328e8b3 ("rtla/timerlat: Add timerlat hist mode") Signed-off-by: Tomas Glozar <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tomas Glozar <[email protected]> Date: Tue Jan 7 15:48:23 2025 +0100 rtla/timerlat_top: Set OSNOISE_WORKLOAD for kernel threads commit 217f0b1e990e30a1f06f6d531fdb4530f4788d48 upstream. When using rtla timerlat with userspace threads (-u or -U), rtla disables the OSNOISE_WORKLOAD option in /sys/kernel/tracing/osnoise/options. This option is not re-enabled in a subsequent run with kernel-space threads, leading to rtla collecting no results if the previous run exited abnormally: $ rtla timerlat top -u ^\Quit (core dumped) $ rtla timerlat top -k -d 1s Timer Latency 0 00:00:01 | IRQ Timer Latency (us) | Thread Timer Latency (us) CPU COUNT | cur min avg max | cur min avg max The issue persists until OSNOISE_WORKLOAD is set manually by running: $ echo OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options Set OSNOISE_WORKLOAD when running rtla with kernel-space threads if available to fix the issue. Cc: [email protected] Cc: John Kacur <[email protected]> Cc: Luis Goncalves <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: cdca4f4e5e8e ("rtla/timerlat_top: Add timerlat user-space support") Signed-off-by: Tomas Glozar <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tomas Glozar <[email protected]> Date: Thu Jan 16 15:49:29 2025 +0100 rtla/timerlat_top: Stop timerlat tracer on signal commit a4dfce7559d75430c464294ddee554be2a413c4a upstream. Currently, when either SIGINT from the user or SIGALRM from the duration timer is caught by rtla-timerlat, stop_tracing is set to break out of the main loop. This is not sufficient for cases where the timerlat tracer is producing more data than rtla can consume, since in that case, rtla is looping indefinitely inside tracefs_iterate_raw_events, never reaches the check of stop_tracing and hangs. In addition to setting stop_tracing, also stop the timerlat tracer on received signal (SIGINT or SIGALRM). This will stop new samples so that the existing samples may be processed and tracefs_iterate_raw_events eventually exits. Cc: [email protected] Cc: John Kacur <[email protected]> Cc: Luis Goncalves <[email protected]> Cc: Gabriele Monaco <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: a828cd18bc4a ("rtla: Add timerlat tool and timelart top mode") Signed-off-by: Tomas Glozar <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tomas Glozar <[email protected]> Date: Thu Jan 16 15:49:27 2025 +0100 rtla: Add trace_instance_stop commit e879b5dcf8d044f3865a32d95cc5b213f314c54f upstream. Support not only turning trace on for the timerlat tracer, but also turning it off. This will be used in subsequent patches to stop the timerlat tracer without also wiping the trace buffer. Cc: [email protected] Cc: John Kacur <[email protected]> Cc: Luis Goncalves <[email protected]> Cc: Gabriele Monaco <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Tomas Glozar <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miguel Ojeda <[email protected]> Date: Tue Jan 21 21:09:34 2025 +0100 rust: init: use explicit ABI to clean warning in future compilers commit c21bdb3d8a850afdfa4afe77eea39ae9533629b0 upstream. Starting with Rust 1.86.0 (currently in nightly, to be released on 2025-04-03), the `missing_abi` lint is warn-by-default [1]: error: extern declarations without an explicit ABI are deprecated --> rust/doctests_kernel_generated.rs:3158:1 | 3158 | extern { | ^^^^^^ help: explicitly specify the C ABI: `extern "C"` | = note: `-D missing-abi` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(missing_abi)]` Thus clean it up. Cc: <[email protected]> # Needed in 6.12.y and 6.13.y only (Rust is pinned in older LTSs). Fixes: 7f8977a7fe6d ("rust: init: add `{pin_}chain` functions to `{Pin}Init<T, E>`") Link: https://github.com/rust-lang/rust/pull/132397 [1] Reviewed-by: Gary Guo <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Fiona Behrens <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Added 6.13.y to Cc: stable tag. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gabriele Monaco <[email protected]> Date: Wed Jan 15 16:15:48 2025 +0100 rv: Reset per-task monitors also for idle tasks commit 8259cb14a70680553d5e82d65d1302fe589e9b39 upstream. RV per-task monitors are implemented through a monitor structure available for each task_struct. This structure is reset every time the monitor is (re-)started, to avoid inconsistencies if the monitor was activated previously. To do so, we reset the monitor on all threads using the macro for_each_process_thread. However, this macro excludes the idle tasks on each CPU. Idle tasks could be considered tasks on their own right and it should be up to the model whether to ignore them or not. Reset monitors also on the idle tasks for each present CPU whenever we reset all per-task monitors. Cc: [email protected] Cc: Juri Lelli <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: John Kacur <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: 792575348ff7 ("rv/include: Add deterministic automata monitor definition via C macros") Signed-off-by: Gabriele Monaco <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Howells <[email protected]> Date: Tue Feb 4 23:05:53 2025 +0000 rxrpc: Fix call state set to not include the SERVER_SECURING state [ Upstream commit 41b996ce83bf944de5569d6263c8dbd5513e7ed0 ] The RXRPC_CALL_SERVER_SECURING state doesn't really belong with the other states in the call's state set as the other states govern the call's Rx/Tx phase transition and govern when packets can and can't be received or transmitted. The "Securing" state doesn't actually govern the reception of packets and would need to be split depending on whether or not we've received the last packet yet (to mirror RECV_REQUEST/ACK_REQUEST). The "Securing" state is more about whether or not we can start forwarding packets to the application as recvmsg will need to decode them and the decoding can't take place until the challenge/response exchange has completed. Fix this by removing the RXRPC_CALL_SERVER_SECURING state from the state set and, instead, using a flag, RXRPC_CALL_CONN_CHALLENGING, to track whether or not we can queue the call for reception by recvmsg() or notify the kernel app that data is ready. In the event that we've already received all the packets, the connection event handler will poke the app layer in the appropriate manner. Also there's a race whereby the app layer sees the last packet before rxrpc has managed to end the rx phase and change the state to one amenable to allowing a reply. Fix this by queuing the packet after calling rxrpc_end_rx_phase(). Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: Simon Horman <[email protected]> cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Howells <[email protected]> Date: Mon Feb 3 11:03:04 2025 +0000 rxrpc: Fix the rxrpc_connection attend queue handling [ Upstream commit 4241a702e0d0c2ca9364cfac08dbf134264962de ] The rxrpc_connection attend queue is never used because conn::attend_link is never initialised and so is always NULL'd out and thus always appears to be busy. This requires the following fix: (1) Fix this the attend queue problem by initialising conn::attend_link. And, consequently, two further fixes for things masked by the above bug: (2) Fix rxrpc_input_conn_event() to handle being invoked with a NULL sk_buff pointer - something that can now happen with the above change. (3) Fix the RXRPC_SKB_MARK_SERVICE_CONN_SECURED message to carry a pointer to the connection and a ref on it. Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: Jakub Kicinski <[email protected]> cc: "David S. Miller" <[email protected]> cc: Eric Dumazet <[email protected]> cc: Paolo Abeni <[email protected]> cc: Simon Horman <[email protected]> cc: [email protected] cc: [email protected] Fixes: f2cce89a074e ("rxrpc: Implement a mechanism to send an event notification to a connection") Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Heiko Carstens <[email protected]> Date: Tue Jan 7 11:28:58 2025 +0100 s390/futex: Fix FUTEX_OP_ANDN implementation commit 26701574cee6777f867f89b4a5c667817e1ee0dd upstream. The futex operation FUTEX_OP_ANDN is supposed to implement *(int *)UADDR2 &= ~OPARG; The s390 implementation just implements an AND instead of ANDN. Add the missing bitwise not operation to oparg to fix this. This is broken since nearly 19 years, so it looks like user space is not making use of this operation. Fixes: 3363fbdd6fb4 ("[PATCH] s390: futex atomic operations") Cc: [email protected] Signed-off-by: Heiko Carstens <[email protected]> Acked-by: Alexander Gordeev <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sven Schnelle <[email protected]> Date: Wed Jan 8 15:27:02 2025 +0100 s390/stackleak: Use exrl instead of ex in __stackleak_poison() [ Upstream commit a88c26bb8e04ee5f2678225c0130a5fbc08eef85 ] exrl is present in all machines currently supported, therefore prefer it over ex. This saves one instruction and doesn't need an additional register to hold the address of the target instruction. Signed-off-by: Sven Schnelle <[email protected]> Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Leo Stone <[email protected]> Date: Tue Dec 17 10:26:57 2024 -0800 safesetid: check size of policy writes [ Upstream commit f09ff307c7299392f1c88f763299e24bc99811c7 ] syzbot attempts to write a buffer with a large size to a sysfs entry with writes handled by handle_policy_update(), triggering a warning in kmalloc. Check the size specified for write buffers before allocating. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=4eb7a741b3216020043a Signed-off-by: Leo Stone <[email protected]> [PM: subject tweak] Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Suleiman Souhlal <[email protected]> Date: Mon Nov 18 13:37:45 2024 +0900 sched: Don't try to catch up excess steal time. [ Upstream commit 108ad0999085df2366dd9ef437573955cb3f5586 ] When steal time exceeds the measured delta when updating clock_task, we currently try to catch up the excess in future updates. However, this results in inaccurate run times for the future things using clock_task, in some situations, as they end up getting additional steal time that did not actually happen. This is because there is a window between reading the elapsed time in update_rq_clock() and sampling the steal time in update_rq_clock_task(). If the VCPU gets preempted between those two points, any additional steal time is accounted to the outgoing task even though the calculated delta did not actually contain any of that "stolen" time. When this race happens, we can end up with steal time that exceeds the calculated delta, and the previous code would try to catch up that excess steal time in future clock updates, which is given to the next, incoming task, even though it did not actually have any time stolen. This behavior is particularly bad when steal time can be very long, which we've seen when trying to extend steal time to contain the duration that the host was suspended [0]. When this happens, clock_task stays frozen, during which the running task stays running for the whole duration, since its run time doesn't increase. However the race can happen even under normal operation. Ideally we would read the elapsed cpu time and the steal time atomically, to prevent this race from happening in the first place, but doing so is non-trivial. Since the time between those two points isn't otherwise accounted anywhere, neither to the outgoing task nor the incoming task (because the "end of outgoing task" and "start of incoming task" timestamps are the same), I would argue that the right thing to do is to simply drop any excess steal time, in order to prevent these issues. [0] https://lore.kernel.org/kvm/[email protected]/ Signed-off-by: Suleiman Souhlal <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jan Kiszka <[email protected]> Date: Fri Jan 10 11:36:33 2025 +0100 scripts/gdb: fix aarch64 userspace detection in get_current_task commit 4ebc417ef9cb34010a71270421fe320ec5d88aa2 upstream. At least recent gdb releases (seen with 14.2) return SP_EL0 as signed long which lets the right-shift always return 0. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Jan Kiszka <[email protected]> Cc: Barry Song <[email protected]> Cc: Kieran Bingham <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quinn Tran <[email protected]> Date: Fri Nov 15 18:33:09 2024 +0530 scsi: qla2xxx: Move FCE Trace buffer allocation to user control commit 841df27d619ee1f5ca6473e15227b39d6136562d upstream. Currently FCE Tracing is enabled to log additional ELS events. Instead, user will enable or disable this feature through debugfs. Modify existing DFS knob to allow user to enable or disable this feature. echo [1 | 0] > /sys/kernel/debug/qla2xxx/qla2xxx_??/fce cat /sys/kernel/debug/qla2xxx/qla2xxx_??/fce Cc: [email protected] Fixes: df613b96077c ("[SCSI] qla2xxx: Add Fibre Channel Event (FCE) tracing support.") Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kai Mäkisara <[email protected]> Date: Mon Dec 16 13:37:55 2024 +0200 scsi: st: Don't set pos_unknown just after device recognition commit 98b37881b7492ae9048ad48260cc8a6ee9eb39fd upstream. Commit 9604eea5bd3a ("scsi: st: Add third party poweron reset handling") in v6.6 added new code to handle the Power On/Reset Unit Attention (POR UA) sense data. This was in addition to the existing method. When this Unit Attention is received, the driver blocks attempts to read, write and some other operations because the reset may have rewinded the tape. Because of the added code, also the initial POR UA resulted in blocking operations, including those that are used to set the driver options after the device is recognized. Also, reading and writing are refused, whereas they succeeded before this commit. Add code to not set pos_unknown to block operations if the POR UA is received from the first test_ready() call after the st device has been created. This restores the behavior before v6.6. Signed-off-by: Kai Mäkisara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: 9604eea5bd3a ("scsi: st: Add third party poweron reset handling") CC: [email protected] Closes: https://lore.kernel.org/linux-scsi/[email protected]/ Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Long Li <[email protected]> Date: Wed Jan 22 19:07:22 2025 -0800 scsi: storvsc: Set correct data length for sending SCSI command without payload commit 87c4b5e8a6b65189abd9ea5010ab308941f964a4 upstream. In StorVSC, payload->range.len is used to indicate if this SCSI command carries payload. This data is allocated as part of the private driver data by the upper layer and may get passed to lower driver uninitialized. For example, the SCSI error handling mid layer may send TEST_UNIT_READY or REQUEST_SENSE while reusing the buffer from a failed command. The private data section may have stale data from the previous command. If the SCSI command doesn't carry payload, the driver may use this value as is for communicating with host, resulting in possible corruption. Fix this by always initializing this value. Fixes: be0cf6ca301c ("scsi: storvsc: Set the tablesize based on the information given by the host") Cc: [email protected] Tested-by: Roman Kisel <[email protected]> Reviewed-by: Roman Kisel <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Signed-off-by: Long Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bao D. Nguyen <[email protected]> Date: Mon Jan 13 10:32:07 2025 -0800 scsi: ufs: core: Fix the HIGH/LOW_TEMP Bit Definitions commit 1b3e2d4ec0c5848776cc56d2624998aa5b2f0d27 upstream. According to the UFS Device Specification, the dExtendedUFSFeaturesSupport defines the support for TOO_HIGH_TEMPERATURE as bit[4] and the TOO_LOW_TEMPERATURE as bit[5]. Correct the code to match with the UFS device specification definition. Cc: [email protected] Fixes: e88e2d32200a ("scsi: ufs: core: Probe for temperature notification support") Signed-off-by: Bao D. Nguyen <[email protected]> Link: https://lore.kernel.org/r/69992b3e3e3434a5c7643be5a64de48be892ca46.1736793068.git.quic_nguyenb@quicinc.com Reviewed-by: Avri Altman <[email protected]> Reviewed-by: Peter Wang <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Mon Dec 9 19:08:39 2024 -0800 scsi: ufs: qcom: Fix crypto key eviction commit 7a0905caf5665be41094a6ceb5e9d2524de4627a upstream. Commit 56541c7c4468 ("scsi: ufs: ufs-qcom: Switch to the new ICE API") introduced an incorrect check of the algorithm ID into the key eviction path, and thus qcom_ice_evict_key() is no longer ever called. Fix it. Fixes: 56541c7c4468 ("scsi: ufs: ufs-qcom: Switch to the new ICE API") Cc: [email protected] Cc: Abel Vesa <[email protected]> Signed-off-by: Eric Biggers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Liu Ye <[email protected]> Date: Thu Jan 16 09:30:37 2025 +0800 selftests/net/ipsec: Fix Null pointer dereference in rtattr_pack() [ Upstream commit 3a0b7fa095212b51ed63892540c4f249991a2d74 ] Address Null pointer dereference / undefined behavior in rtattr_pack (note that size is 0 in the bad case). Flagged by cppcheck as: tools/testing/selftests/net/ipsec.c:230:25: warning: Possible null pointer dereference: payload [nullPointer] memcpy(RTA_DATA(attr), payload, size); ^ tools/testing/selftests/net/ipsec.c:1618:54: note: Calling function 'rtattr_pack', 4th argument 'NULL' value is 0 if (rtattr_pack(&req.nh, sizeof(req), XFRMA_IF_ID, NULL, 0)) { ^ tools/testing/selftests/net/ipsec.c:230:25: note: Null pointer dereference memcpy(RTA_DATA(attr), payload, size); ^ Signed-off-by: Liu Ye <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Tue Feb 4 23:19:53 2025 +0100 selftests: mptcp: connect: -f: no reconnect commit 5368a67307b3b2c347dc8965ac55b888be665934 upstream. The '-f' parameter is there to force the kernel to emit MPTCP FASTCLOSE by closing the connection with unread bytes in the receive queue. The xdisconnect() helper was used to stop the connection, but it does more than that: it will shut it down, then wait before reconnecting to the same address. This causes the mptcp_join's "fastclose test" to fail all the time. This failure is due to a recent change, with commit 218cc166321f ("selftests: mptcp: avoid spurious errors on disconnect"), but that went unnoticed because the test is currently ignored. The recent modification only shown an existing issue: xdisconnect() doesn't need to be used here, only the shutdown() part is needed. Fixes: 6bf41020b72b ("selftests: mptcp: update and extend fastclose test-cases") Cc: [email protected] Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Sun Feb 9 18:41:57 2025 +0100 selftests: mptcp: join: fix AF_INET6 variable The Fixes commit is a backport renaming a variable, from AF_INET6 to MPTCP_LIB_AF_INET6. The commit has been applied without conflicts, except that it missed one extra variable that was in v6.6, but not in the version linked to the Fixes commit. This variable has then been renamed too to avoid these errors: LISTENER_CREATED 10.0.2.1:10100 ./mptcp_join.sh: line 2944: [: 2: unary operator expected LISTENER_CLOSED 10.0.2.1:10100 ./mptcp_join.sh: line 2944: [: 2: unary operator expected Fixes: a17d1419126b ("selftests: mptcp: declare event macros in mptcp_lib") Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Claudiu Beznea <[email protected]> Date: Thu Jan 16 20:22:47 2025 +0200 serial: sh-sci: Do not probe the serial port if its slot in sci_ports[] is in use commit 9f7dea875cc7f9c1a56a5c688290634a59cd1420 upstream. In the sh-sci driver, sci_ports[0] is used by earlycon. If the earlycon is still active when sci_probe() is called and the new serial port is supposed to map to sci_ports[0], return -EBUSY to prevent breaking the earlycon. This situation should occurs in debug scenarios, and users should be aware of the potential conflict. Fixes: 0b0cced19ab1 ("serial: sh-sci: Add CONFIG_SERIAL_EARLYCON support") Cc: [email protected] Signed-off-by: Claudiu Beznea <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Claudiu Beznea <[email protected]> Date: Thu Jan 16 20:22:45 2025 +0200 serial: sh-sci: Drop __initdata macro for port_cfg commit eaeee4225dba30bef4d424bdf134a07b7f423e8b upstream. The port_cfg object is used by serial_console_write(), which serves as the write function for the earlycon device. Marking port_cfg as __initdata causes it to be freed after kernel initialization, resulting in earlycon becoming unavailable thereafter. Remove the __initdata macro from port_cfg to resolve this issue. Fixes: 0b0cced19ab1 ("serial: sh-sci: Add CONFIG_SERIAL_EARLYCON support") Cc: [email protected] Reviewed-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Claudiu Beznea <[email protected]> Fixes: 0b0cced19ab15c9e ("serial: sh-sci: Add CONFIG_SERIAL_EARLYCON support") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Meetakshi Setiya <[email protected]> Date: Thu Feb 6 01:50:41 2025 -0500 smb: client: change lease epoch type from unsigned int to __u16 commit 57e4a9bd61c308f607bc3e55e8fa02257b06b552 upstream. MS-SMB2 section 2.2.13.2.10 specifies that 'epoch' should be a 16-bit unsigned integer used to track lease state changes. Change the data type of all instances of 'epoch' from unsigned int to __u16. This simplifies the epoch change comparisons and makes the code more compliant with the protocol spec. Cc: [email protected] Signed-off-by: Meetakshi Setiya <[email protected]> Reviewed-by: Shyam Prasad N <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ruben Devos <[email protected]> Date: Sat Jan 18 21:03:30 2025 +0100 smb: client: fix order of arguments of tracepoints commit 11f8b80ab9f99291dc88d09855b9f8f43b772335 upstream. The tracepoints based on smb3_inf_compound_*_class have tcon id and session id swapped around. This results in incorrect output in `trace-cmd report`. Fix the order of arguments to resolve this issue. The trace-cmd output below shows the before and after of the smb3_delete_enter and smb3_delete_done events as an example. The smb3_cmd_* events show the correct session and tcon id for reference. Also fix tracepoint set -> get in the SMB2_OP_GET_REPARSE case. BEFORE: rm-2211 [001] ..... 1839.550888: smb3_delete_enter: xid=281 sid=0x5 tid=0x3d path=\hello2.txt rm-2211 [001] ..... 1839.550894: smb3_cmd_enter: sid=0x1ac000000003d tid=0x5 cmd=5 mid=61 rm-2211 [001] ..... 1839.550896: smb3_cmd_enter: sid=0x1ac000000003d tid=0x5 cmd=6 mid=62 rm-2211 [001] ..... 1839.552091: smb3_cmd_done: sid=0x1ac000000003d tid=0x5 cmd=5 mid=61 rm-2211 [001] ..... 1839.552093: smb3_cmd_done: sid=0x1ac000000003d tid=0x5 cmd=6 mid=62 rm-2211 [001] ..... 1839.552103: smb3_delete_done: xid=281 sid=0x5 tid=0x3d AFTER: rm-2501 [001] ..... 3237.656110: smb3_delete_enter: xid=88 sid=0x1ac0000000041 tid=0x5 path=\hello2.txt rm-2501 [001] ..... 3237.656122: smb3_cmd_enter: sid=0x1ac0000000041 tid=0x5 cmd=5 mid=84 rm-2501 [001] ..... 3237.656123: smb3_cmd_enter: sid=0x1ac0000000041 tid=0x5 cmd=6 mid=85 rm-2501 [001] ..... 3237.657909: smb3_cmd_done: sid=0x1ac0000000041 tid=0x5 cmd=5 mid=84 rm-2501 [001] ..... 3237.657909: smb3_cmd_done: sid=0x1ac0000000041 tid=0x5 cmd=6 mid=85 rm-2501 [001] ..... 3237.657922: smb3_delete_done: xid=88 sid=0x1ac0000000041 tid=0x5 Cc: [email protected] Signed-off-by: Ruben Devos <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Sat Jan 4 15:20:11 2025 +0100 soc: mediatek: mtk-devapc: Fix leaking IO map on error paths commit c0eb059a4575ed57f265d9883a5203799c19982c upstream. Error paths of mtk_devapc_probe() should unmap the memory. Reported by Smatch: drivers/soc/mediatek/mtk-devapc.c:292 mtk_devapc_probe() warn: 'ctx->infra_base' from of_iomap() not released on lines: 277,281,286. Fixes: 0890beb22618 ("soc: mediatek: add mt6779 devapc driver") Cc: [email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Thu Aug 22 18:48:51 2024 +0200 soc: qcom: smem_state: fix missing of_node_put in error path commit 70096b4990848229d0784c5e51dc3c7c072f1111 upstream. If of_parse_phandle_with_args() succeeds, the OF node reference should be dropped, regardless of number of phandle arguments. Cc: [email protected] Fixes: 9460ae2ff308 ("soc: qcom: Introduce common SMEM state machine code") Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Stephan Gerhold <[email protected]> Date: Mon Dec 30 20:59:35 2024 +0100 soc: qcom: socinfo: Avoid out of bounds read of serial number commit 22cf4fae6660b6e1a583a41cbf84e3046ca9ccd0 upstream. On MSM8916 devices, the serial number exposed in sysfs is constant and does not change across individual devices. It's always: db410c:/sys/devices/soc0$ cat serial_number 2644893864 The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not have support for the serial_num field in the socinfo struct. There is an existing check to avoid exposing the serial number in that case, but it's not correct: When checking the item_size returned by SMEM, we need to make sure the *end* of the serial_num is within bounds, instead of comparing with the *start* offset. The serial_number currently exposed on MSM8916 devices is just an out of bounds read of whatever comes after the socinfo struct in SMEM. Fix this by changing offsetof() to offsetofend(), so that the size of the field is also taken into account. Cc: [email protected] Fixes: efb448d0a3fc ("soc: qcom: Add socinfo driver") Signed-off-by: Stephan Gerhold <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bence Csókás <[email protected]> Date: Thu Dec 19 10:12:58 2024 +0100 spi: atmel-qspi: Memory barriers after memory-mapped I/O commit be92ab2de0ee1a13291c3b47b2d7eb24d80c0a2c upstream. The QSPI peripheral control and status registers are accessible via the SoC's APB bus, whereas MMIO transactions' data travels on the AHB bus. Microchip documentation and even sample code from Atmel emphasises the need for a memory barrier before the first MMIO transaction to the AHB-connected QSPI, and before the last write to its registers via APB. This is achieved by the following lines in `atmel_qspi_transfer()`: /* Dummy read of QSPI_IFR to synchronize APB and AHB accesses */ (void)atmel_qspi_read(aq, QSPI_IFR); However, the current documentation makes no mention to synchronization requirements in the other direction, i.e. after the last data written via AHB, and before the first register access on APB. In our case, we were facing an issue where the QSPI peripheral would cease to send any new CSR (nCS Rise) interrupts, leading to a timeout in `atmel_qspi_wait_for_completion()` and ultimately this panic in higher levels: ubi0 error: ubi_io_write: error -110 while writing 63108 bytes to PEB 491:128, written 63104 bytes After months of extensive research of the codebase, fiddling around the debugger with kgdb, and back-and-forth with Microchip, we came to the conclusion that the issue is probably that the peripheral is still busy receiving on AHB when the LASTXFER bit is written to its Control Register on APB, therefore this write gets lost, and the peripheral still thinks there is more data to come in the MMIO transfer. This was first formulated when we noticed that doubling the write() of QSPI_CR_LASTXFER seemed to solve the problem. Ultimately, the solution is to introduce memory barriers after the AHB-mapped MMIO transfers, to ensure ordering. Fixes: d5433def3153 ("mtd: spi-nor: atmel-quadspi: Add spi-mem support to atmel-quadspi") Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] # c0a0203cf579: ("spi: atmel-quadspi: Create `atmel_qspi_ops`"...) Cc: [email protected] # 6.x.y Signed-off-by: Bence Csókás <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Csókás, Bence <[email protected]> Date: Thu Nov 28 18:43:14 2024 +0100 spi: atmel-quadspi: Create `atmel_qspi_ops` to support newer SoC families commit c0a0203cf57963792d59b3e4317a1d07b73df42a upstream. Refactor the code to introduce an ops struct, to prepare for merging support for later SoCs, such as SAMA7G5. This code was based on the vendor's kernel (linux4microchip). Cc'ing original contributors. Signed-off-by: Csókás, Bence <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lenny Szubowicz <[email protected]> Date: Thu Jan 30 16:57:54 2025 -0500 tg3: Disable tg3 PCIe AER on system reboot [ Upstream commit e0efe83ed325277bb70f9435d4d9fc70bebdcca8 ] Disable PCIe AER on the tg3 device on system reboot on a limited list of Dell PowerEdge systems. This prevents a fatal PCIe AER event on the tg3 device during the ACPI _PTS (prepare to sleep) method for S5 on those systems. The _PTS is invoked by acpi_enter_sleep_state_prep() as part of the kernel's reboot sequence as a result of commit 38f34dba806a ("PM: ACPI: reboot: Reinstate S5 for reboot"). There was an earlier fix for this problem by commit 2ca1c94ce0b6 ("tg3: Disable tg3 device on system reboot to avoid triggering AER"). But it was discovered that this earlier fix caused a reboot hang when some Dell PowerEdge servers were booted via ipxe. To address this reboot hang, the earlier fix was essentially reverted by commit 9fc3bc764334 ("tg3: power down device only on SYSTEM_POWER_OFF"). This re-exposed the tg3 PCIe AER on reboot problem. This fix is not an ideal solution because the root cause of the AER is in system firmware. Instead, it's a targeted work-around in the tg3 driver. Note also that the PCIe AER must be disabled on the tg3 device even if the system is configured to use "firmware first" error handling. V3: - Fix sparse warning on improper comparison of pdev->current_state - Adhere to netdev comment style Fixes: 9fc3bc764334 ("tg3: power down device only on SYSTEM_POWER_OFF") Signed-off-by: Lenny Szubowicz <[email protected]> Reviewed-by: Pavan Chebbi <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Fri Jan 17 12:36:14 2025 +0300 tipc: re-order conditions in tipc_crypto_key_rcv() [ Upstream commit 5fe71fda89745fc3cd95f70d06e9162b595c3702 ] On a 32bit system the "keylen + sizeof(struct tipc_aead_key)" math could have an integer wrapping issue. It doesn't matter because the "keylen" is checked on the next line, but just to make life easier for static analysis tools, let's re-order these conditions and avoid the integer overflow. Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tetsuo Handa <[email protected]> Date: Mon Dec 16 19:38:40 2024 +0900 tomoyo: don't emit warning in tomoyo_write_control() [ Upstream commit 3df7546fc03b8f004eee0b9e3256369f7d096685 ] syzbot is reporting too large allocation warning at tomoyo_write_control(), for one can write a very very long line without new line character. To fix this warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE, for practically a valid line should be always shorter than 32KB where the "too small to fail" memory-allocation rule applies. One might try to write a valid line that is longer than 32KB, but such request will likely fail with -ENOMEM. Therefore, I feel that separately returning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant. There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=7536f77535e5210a5c76 Reported-by: Leo Stone <[email protected]> Closes: https://lkml.kernel.org/r/[email protected] Signed-off-by: Tetsuo Handa <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jarkko Sakkinen <[email protected]> Date: Fri Dec 27 17:39:09 2024 +0200 tpm: Change to kvalloc() in eventlog/acpi.c commit a3a860bc0fd6c07332e4911cf9a238d20de90173 upstream. The following failure was reported on HPE ProLiant D320: [ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0 The above transcript shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof(). Address the bug by moving from devm_kmalloc() to devm_add_action() and kvmalloc() and devm_add_action(). Suggested-by: Ard Biesheuvel <[email protected]> Cc: [email protected] # v2.6.16+ Fixes: 55a82ab3181b ("[PATCH] tpm: add bios measurement log") Reported-by: Andy Liang <[email protected]> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219495 Reviewed-by: Ard Biesheuvel <[email protected]> Reviewed-by: Stefan Berger <[email protected]> Reviewed-by: Takashi Iwai <[email protected]> Tested-by: Andy Liang <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Steven Rostedt <[email protected]> Date: Thu Jan 23 20:41:59 2025 -0500 tracing/osnoise: Fix resetting of tracepoints commit e3ff4245928f948f3eb2e852aa350b870421c358 upstream. If a timerlat tracer is started with the osnoise option OSNOISE_WORKLOAD disabled, but then that option is enabled and timerlat is removed, the tracepoints that were enabled on timerlat registration do not get disabled. If the option is disabled again and timelat is started, then it triggers a warning in the tracepoint code due to registering the tracepoint again without ever disabling it. Do not use the same user space defined options to know to disable the tracepoints when timerlat is removed. Instead, set a global flag when it is enabled and use that flag to know to disable the events. ~# echo NO_OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options ~# echo timerlat > /sys/kernel/tracing/current_tracer ~# echo OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options ~# echo nop > /sys/kernel/tracing/current_tracer ~# echo NO_OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options ~# echo timerlat > /sys/kernel/tracing/current_tracer Triggers: ------------[ cut here ]------------ WARNING: CPU: 6 PID: 1337 at kernel/tracepoint.c:294 tracepoint_add_func+0x3b6/0x3f0 Modules linked in: CPU: 6 UID: 0 PID: 1337 Comm: rtla Not tainted 6.13.0-rc4-test-00018-ga867c441128e-dirty #73 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tracepoint_add_func+0x3b6/0x3f0 Code: 48 8b 53 28 48 8b 73 20 4c 89 04 24 e8 23 59 11 00 4c 8b 04 24 e9 36 fe ff ff 0f 0b b8 ea ff ff ff 45 84 e4 0f 84 68 fe ff ff <0f> 0b e9 61 fe ff ff 48 8b 7b 18 48 85 ff 0f 84 4f ff ff ff 49 8b RSP: 0018:ffffb9b003a87ca0 EFLAGS: 00010202 RAX: 00000000ffffffef RBX: ffffffff92f30860 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9bf59e91ccd0 RDI: ffffffff913b6410 RBP: 000000000000000a R08: 00000000000005c7 R09: 0000000000000002 R10: ffffb9b003a87ce0 R11: 0000000000000002 R12: 0000000000000001 R13: ffffb9b003a87ce0 R14: ffffffffffffffef R15: 0000000000000008 FS: 00007fce81209240(0000) GS:ffff9bf6fdd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055e99b728000 CR3: 00000001277c0002 CR4: 0000000000172ef0 Call Trace: <TASK> ? __warn.cold+0xb7/0x14d ? tracepoint_add_func+0x3b6/0x3f0 ? report_bug+0xea/0x170 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? __pfx_trace_sched_migrate_callback+0x10/0x10 ? tracepoint_add_func+0x3b6/0x3f0 ? __pfx_trace_sched_migrate_callback+0x10/0x10 ? __pfx_trace_sched_migrate_callback+0x10/0x10 tracepoint_probe_register+0x78/0xb0 ? __pfx_trace_sched_migrate_callback+0x10/0x10 osnoise_workload_start+0x2b5/0x370 timerlat_tracer_init+0x76/0x1b0 tracing_set_tracer+0x244/0x400 tracing_set_trace_write+0xa0/0xe0 vfs_write+0xfc/0x570 ? do_sys_openat2+0x9c/0xe0 ksys_write+0x72/0xf0 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Tomas Glozar <[email protected]> Cc: Gabriele Monaco <[email protected]> Cc: Luis Goncalves <[email protected]> Cc: John Kacur <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: e88ed227f639e ("tracing/timerlat: Add user-space interface") Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Anderson <[email protected]> Date: Fri Jan 10 16:38:22 2025 -0500 tty: xilinx_uartps: split sysrq handling commit b06f388994500297bb91be60ffaf6825ecfd2afe upstream. lockdep detects the following circular locking dependency: CPU 0 CPU 1 ========================== ============================ cdns_uart_isr() printk() uart_port_lock(port) console_lock() cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock() The fixed commit attempts to avoid this situation by only taking the port lock in cdns_uart_console_write if port->sysrq unset. However, if (as shown above) cdns_uart_console_write runs before port->sysrq is set, then it will try to take the port lock anyway. This may result in a deadlock. Fix this by splitting sysrq handling into two parts. We use the prepare helper under the port lock and defer handling until we release the lock. Fixes: 74ea66d4ca06 ("tty: xuartps: Improve sysrq handling") Signed-off-by: Sean Anderson <[email protected]> Cc: [email protected] # c980248179d: serial: xilinx_uartps: Use port lock wrappers Acked-by: John Ogness <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Anderson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Stas Sergeev <[email protected]> Date: Thu Dec 5 10:36:14 2024 +0300 tun: fix group permission check [ Upstream commit 3ca459eaba1bf96a8c7878de84fa8872259a01e3 ] Currently tun checks the group permission even if the user have matched. Besides going against the usual permission semantic, this has a very interesting implication: if the tun group is not among the supplementary groups of the tun user, then effectively no one can access the tun device. CAP_SYS_ADMIN still can, but its the same as not setting the tun ownership. This patch relaxes the group checking so that either the user match or the group match is enough. This avoids the situation when no one can access the device even though the ownership is properly set. Also I simplified the logic by removing the redundant inversions: tun_not_capable() --> !tun_capable() Signed-off-by: Stas Sergeev <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Acked-by: Jason Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Willem de Bruijn <[email protected]> Date: Tue Feb 4 11:10:06 2025 -0500 tun: revert fix group permission check [ Upstream commit a70c7b3cbc0688016810bb2e0b9b8a0d6a530045 ] This reverts commit 3ca459eaba1bf96a8c7878de84fa8872259a01e3. The blamed commit caused a regression when neither tun->owner nor tun->group is set. This is intended to be allowed, but now requires CAP_NET_ADMIN. Discussion in the referenced thread pointed out that the original issue that prompted this patch can be resolved in userspace. The relaxed access control may also make a device accessible when it previously wasn't, while existing users may depend on it to not be. This is a clean pure git revert, except for fixing the indentation on the gid_valid line that checkpatch correctly flagged. Fixes: 3ca459eaba1b ("tun: fix group permission check") Link: https://lore.kernel.org/netdev/CAFqZXNtkCBT4f+PwyVRmQGoT3p1eVa01fCG_aNtpt6dakXncUg@mail.gmail.com/ Signed-off-by: Willem de Bruijn <[email protected]> Cc: Ondrej Mosnacek <[email protected]> Cc: Stas Sergeev <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Denis Arefev <[email protected]> Date: Mon Dec 2 12:36:52 2024 +0300 ubi: Add a check for ubi_num commit 97bbf9e312c3fbaf0baa56120238825d2eb23b8a upstream. Added a check for ubi_num for negative numbers If the variable ubi_num takes negative values then we get: qemu-system-arm ... -append "ubi.mtd=0,0,0,-22222345" ... [ 0.745065] ubi_attach_mtd_dev from ubi_init+0x178/0x218 [ 0.745230] ubi_init from do_one_initcall+0x70/0x1ac [ 0.745344] do_one_initcall from kernel_init_freeable+0x198/0x224 [ 0.745474] kernel_init_freeable from kernel_init+0x18/0x134 [ 0.745600] kernel_init from ret_from_fork+0x14/0x28 [ 0.745727] Exception stack(0x90015fb0 to 0x90015ff8) Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 83ff59a06663 ("UBI: support ubi_num on mtd.ubi command line") Cc: [email protected] Signed-off-by: Denis Arefev <[email protected]> Reviewed-by: Zhihao Cheng <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yan Zhai <[email protected]> Date: Fri Jan 31 00:31:39 2025 -0800 udp: gso: do not drop small packets when PMTU reduces [ Upstream commit 235174b2bed88501fda689c113c55737f99332d8 ] Commit 4094871db1d6 ("udp: only do GSO if # of segs > 1") avoided GSO for small packets. But the kernel currently dismisses GSO requests only after checking MTU/PMTU on gso_size. This means any packets, regardless of their payload sizes, could be dropped when PMTU becomes smaller than requested gso_size. We encountered this issue in production and it caused a reliability problem that new QUIC connection cannot be established before PMTU cache expired, while non GSO sockets still worked fine at the same time. Ideally, do not check any GSO related constraints when payload size is smaller than requested gso_size, and return EMSGSIZE instead of EINVAL on MTU/PMTU check failure to be more specific on the error cause. Fixes: 4094871db1d6 ("udp: only do GSO if # of segs > 1") Signed-off-by: Yan Zhai <[email protected]> Suggested-by: Willem de Bruijn <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thinh Nguyen <[email protected]> Date: Wed Dec 11 00:31:48 2024 +0000 usb: gadget: f_tcm: Decrement command ref count on cleanup commit 3b2a52e88ab0c9469eaadd4d4c8f57d072477820 upstream. We submitted the command with TARGET_SCF_ACK_KREF, which requires acknowledgment of command completion. If the command fails, make sure to decrement the ref count. Fixes: cff834c16d23 ("usb-gadget/tcm: Convert to TARGET_SCF_ACK_KREF I/O krefs") Cc: [email protected] Signed-off-by: Thinh Nguyen <[email protected]> Link: https://lore.kernel.org/r/3c667b4d9c8b0b580346a69ff53616b6a74cfea2.1733876548.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thinh Nguyen <[email protected]> Date: Wed Dec 11 00:32:07 2024 +0000 usb: gadget: f_tcm: Don't prepare BOT write request twice commit 94d9bf671ae314cacc2d7bf96bd233b4abc7cede upstream. The duplicate kmalloc here is causing memory leak. The request preparation in bot_send_write_request is also done in usbg_prepare_w_request. Remove the duplicate work. Fixes: c52661d60f63 ("usb-gadget: Initial merge of target module for UASP + BOT") Cc: [email protected] Signed-off-by: Thinh Nguyen <[email protected]> Link: https://lore.kernel.org/r/f4f26c3d586cde0d46f8c3bcb4e8ae32311b650d.1733876548.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thinh Nguyen <[email protected]> Date: Wed Dec 11 00:32:01 2024 +0000 usb: gadget: f_tcm: ep_autoconfig with fullspeed endpoint commit 25224c1f07d31c261d04dfbc705a7a0f314a825d upstream. Match usb endpoint using fullspeed endpoint descriptor to make sure the wMaxPacketSize for fullspeed descriptors is automatically configured. Fixes: c52661d60f63 ("usb-gadget: Initial merge of target module for UASP + BOT") Cc: [email protected] Signed-off-by: Thinh Nguyen <[email protected]> Link: https://lore.kernel.org/r/e4507bc824aed6e7c7f5a718392ab6a7c1480a7f.1733876548.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thinh Nguyen <[email protected]> Date: Wed Dec 11 00:31:43 2024 +0000 usb: gadget: f_tcm: Translate error to sense commit 98fa00fd3ae43b857b4976984a135483d89d9281 upstream. When respond with check_condition error status, clear from_transport input so the target layer can translate the sense reason reported by f_tcm. Fixes: c52661d60f63 ("usb-gadget: Initial merge of target module for UASP + BOT") Cc: [email protected] Signed-off-by: Thinh Nguyen <[email protected]> Link: https://lore.kernel.org/r/b2a5577efe7abd0af0051229622cf7d3be5cdcd0.1733876548.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Foster Snowhill <[email protected]> Date: Sun Jan 26 00:54:07 2025 +0100 usbnet: ipheth: break up NCM header size computation commit efcbc678a14be268040ffc1fa33c98faf2d55141 upstream. Originally, the total NCM header size was computed as the sum of two vaguely labelled constants. While accurate, it wasn't particularly clear where they were coming from. Use sizes of existing NCM structs where available. Define the total NDP16 size based on the maximum amount of DPEs that can fit into the iOS-specific fixed-size header. This change does not fix any particular issue. Rather, it introduces intermediate constants that will simplify subsequent commits. It should also make it clearer for the reader where the constant values come from. Cc: [email protected] # 6.5.x Signed-off-by: Foster Snowhill <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Foster Snowhill <[email protected]> Date: Sun Jan 26 00:54:04 2025 +0100 usbnet: ipheth: check that DPE points past NCM header commit 429fa68b58cefb9aa9de27e4089637298b46b757 upstream. By definition, a DPE points at the start of a network frame/datagram. Thus it makes no sense for it to point at anything that's part of the NCM header. It is not a security issue, but merely an indication of a malformed DPE. Enforce that all DPEs point at the data portion of the URB, past the NCM header. Fixes: a2d274c62e44 ("usbnet: ipheth: add CDC NCM support") Cc: [email protected] Signed-off-by: Foster Snowhill <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Foster Snowhill <[email protected]> Date: Sun Jan 26 00:54:09 2025 +0100 usbnet: ipheth: document scope of NCM implementation commit be154b598fa54136e2be17d6dd13c8a8bc0078ce upstream. Clarify that the "NCM" implementation in `ipheth` is very limited, as iOS devices aren't compatible with the CDC NCM specification in regular tethering mode. For a standards-compliant implementation, one shall turn to the `cdc_ncm` module. Cc: [email protected] # 6.5.x Signed-off-by: Foster Snowhill <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Foster Snowhill <[email protected]> Date: Sun Jan 26 00:54:08 2025 +0100 usbnet: ipheth: fix DPE OoB read commit ee591f2b281721171896117f9946fced31441418 upstream. Fix an out-of-bounds DPE read, limit the number of processed DPEs to the amount that fits into the fixed-size NDP16 header. Fixes: a2d274c62e44 ("usbnet: ipheth: add CDC NCM support") Cc: [email protected] Signed-off-by: Foster Snowhill <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Foster Snowhill <[email protected]> Date: Sun Jan 26 00:54:03 2025 +0100 usbnet: ipheth: fix possible overflow in DPE length check commit c219427ed296f94bb4b91d08626776dc7719ee27 upstream. Originally, it was possible for the DPE length check to overflow if wDatagramIndex + wDatagramLength > U16_MAX. This could lead to an OoB read. Move the wDatagramIndex term to the other side of the inequality. An existing condition ensures that wDatagramIndex < urb->actual_length. Fixes: a2d274c62e44 ("usbnet: ipheth: add CDC NCM support") Cc: [email protected] Signed-off-by: Foster Snowhill <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Foster Snowhill <[email protected]> Date: Sun Jan 26 00:54:06 2025 +0100 usbnet: ipheth: refactor NCM datagram loop commit 2a9a196429e98fcc64078366c2679bc40aba5466 upstream. Introduce an rx_error label to reduce repetitions in the header signature checks. Store wDatagramIndex and wDatagramLength after endianness conversion to avoid repeated le16_to_cpu() calls. Rewrite the loop to return on a null trailing DPE, which is required by the CDC NCM spec. In case it is missing, fall through to rx_error. This change does not fix any particular issue. Its purpose is to simplify a subsequent commit that fixes a potential OoB read by limiting the maximum amount of processed DPEs. Cc: [email protected] # 6.5.x Signed-off-by: Foster Snowhill <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Foster Snowhill <[email protected]> Date: Sun Jan 26 00:54:05 2025 +0100 usbnet: ipheth: use static NDP16 location in URB commit 86586dcb75cb8fd062a518aca8ee667938b91efb upstream. Original code allowed for the start of NDP16 to be anywhere within the URB based on the `wNdpIndex` value in NTH16. Only the start position of NDP16 was checked, so it was possible for even the fixed-length part of NDP16 to extend past the end of URB, leading to an out-of-bounds read. On iOS devices, the NDP16 header always directly follows NTH16. Rely on and check for this specific format. This, along with NCM-specific minimal URB length check that already exists, will ensure that the fixed-length part of NDP16 plus a set amount of DPEs fit within the URB. Note that this commit alone does not fully address the OoB read. The limit on the amount of DPEs needs to be enforced separately. Fixes: a2d274c62e44 ("usbnet: ipheth: add CDC NCM support") Cc: [email protected] Signed-off-by: Foster Snowhill <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Williamson <[email protected]> Date: Wed Jan 22 10:38:30 2025 -0700 vfio/platform: check the bounds of read/write syscalls commit ce9ff21ea89d191e477a02ad7eabf4f996b80a69 upstream. count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device. Fixes: 6e3f26456009 (“vfio/platform: read and write support for the device fd”) Cc: [email protected] Reported-by: Mostafa Saleh <[email protected]> Reviewed-by: Eric Auger <[email protected]> Reviewed-by: Mostafa Saleh <[email protected]> Tested-by: Mostafa Saleh <[email protected]> Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sankararaman Jayaraman <[email protected]> Date: Fri Jan 31 09:53:41 2025 +0530 vmxnet3: Fix tx queue race condition with XDP [ Upstream commit 3f1baa91a1fdf3de9dbad4bd615b35fab347874b ] If XDP traffic runs on a CPU which is greater than or equal to the number of the Tx queues of the NIC, then vmxnet3_xdp_get_tq() always picks up queue 0 for transmission as it uses reciprocal scale instead of simple modulo operation. vmxnet3_xdp_xmit() and vmxnet3_xdp_xmit_frame() use the above returned queue without any locking which can lead to race conditions when multiple XDP xmits run in parallel on different CPU's. This patch uses a simple module scheme when the current CPU equals or exceeds the number of Tx queues on the NIC. It also adds locking in vmxnet3_xdp_xmit() and vmxnet3_xdp_xmit_frame() functions. Fixes: 54f00cce1178 ("vmxnet3: Add XDP support.") Signed-off-by: Sankararaman Jayaraman <[email protected]> Signed-off-by: Ronak Doshi <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Dösinger <[email protected]> Date: Mon Jan 6 20:09:58 2025 +0300 wifi: brcmfmac: Check the return value of of_property_read_string_index() [ Upstream commit 082d9e263af8de68f0c34f67b251818205160f6e ] Somewhen between 6.10 and 6.11 the driver started to crash on my MacBookPro14,3. The property doesn't exist and 'tmp' remains uninitialized, so we pass a random pointer to devm_kstrdup(). The crash I am getting looks like this: BUG: unable to handle page fault for address: 00007f033c669379 PF: supervisor read access in kernel mode PF: error_code(0x0001) - permissions violation PGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025 Oops: Oops: 0001 [#1] SMP PTI CPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1 Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024 RIP: 0010:strlen+0x4/0x30 Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc RSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202 RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001 RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379 RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a R10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8 R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30 FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x149/0x4c0 ? raw_spin_rq_lock_nested+0xe/0x20 ? sched_balance_newidle+0x22b/0x3c0 ? update_load_avg+0x78/0x770 ? exc_page_fault+0x6f/0x150 ? asm_exc_page_fault+0x26/0x30 ? __pfx_pci_conf1_write+0x10/0x10 ? strlen+0x4/0x30 devm_kstrdup+0x25/0x70 brcmf_of_probe+0x273/0x350 [brcmfmac] Signed-off-by: Stefan Dösinger <[email protected]> Acked-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Marcel Hamer <[email protected]> Date: Thu Jan 16 14:22:40 2025 +0100 wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize() commit 68abd0c4ebf24cd499841a488b97a6873d5efabb upstream. On removal of the device or unloading of the kernel module a potential NULL pointer dereference occurs. The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if() Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated to BRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches. After brcmf_remove_interface() call the brcmf_proto_detach() function is called providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize() Since brcmf_get_ip() can and actually will return NULL in this case the call to brcmf_txfinalize() will result in a NULL pointer dereference inside brcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors. This will only happen if a flowring still has an skb. Although the NULL pointer dereference has only been seen when trying to update the tx statistic, all other uses of the ifp pointer have been guarded as well with an early return if ifp is NULL. Cc: [email protected] Signed-off-by: Marcel Hamer <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Acked-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Antipov <[email protected]> Date: Tue Dec 10 10:04:41 2024 +0300 wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() [ Upstream commit 3f4a0948c3524ae50f166dbc6572a3296b014e62 ] In 'wlc_phy_iqcal_gainparams_nphy()', add gain range check to WARN() instead of possible out-of-bounds 'tbl_iqcal_gainparams_nphy' access. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Antipov <[email protected]> Acked-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Miri Korenblit <[email protected]> Date: Sat Dec 28 22:34:15 2024 +0200 wifi: iwlwifi: avoid memory leak [ Upstream commit 80e96206a3ef348fbd658d98f2f43149c36df8bc ] A caller of iwl_acpi_get_dsm_object must free the returned object. iwl_acpi_get_dsm_integer returns immediately without freeing it if the expected size is more than 8 bytes. Fix that. Note that with the current code this will never happen, since the caller of iwl_acpi_get_dsm_integer already checks that the expected size if either 1 or 4 bytes, so it can't exceed 8 bytes. While at it, print the DSM value instead of the return value, as this was the intention in the first place. Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20241228223206.bf61eaab99f8.Ibdc5df02f885208c222456d42c889c43b7e3b2f7@changeid Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shayne Chen <[email protected]> Date: Thu Oct 10 10:38:16 2024 +0200 wifi: mt76: mt7915: add module param to select 5 GHz or 6 GHz on MT7916 commit 57af267d2b8f5d88485c6372761386d79c5e6a1a upstream. Due to a limitation in available memory, the MT7916 firmware can only handle either 5 GHz or 6 GHz at a time. It does not support runtime switching without a full restart. On older firmware, this accidentally worked to some degree due to missing checks, but couldn't be supported properly, because it left the 6 GHz channels uncalibrated. Newer firmware refuses to start on either band if the passed EEPROM data indicates support for both. Deal with this limitation by using a module parameter to specify the preferred band in case both are supported. Fixes: b4d093e321bd ("mt76: mt7915: add 6 GHz support") Cc: [email protected] Signed-off-by: Shayne Chen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nick Morrow <[email protected]> Date: Thu Dec 19 08:12:14 2024 -0600 wifi: mt76: mt7921u: Add VID/PID for TP-Link TXE50UH commit 47d9a8ba1d7f31c674b6936b3c34ee934aa9b420 upstream. Add VID/PID 35bc/0107 for recently released TP-Link TXE50UH USB WiFi adapter. Tested-by: Shang Chieh Tseng <[email protected]> Signed-off-by: Nick Morrow <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bitterblue Smith <[email protected]> Date: Wed Dec 18 00:53:11 2024 +0200 wifi: rtlwifi: rtl8821ae: Fix media status report commit 66ef0289ac99e155d206ddaa0fdfad09ae3cd007 upstream. RTL8821AE is stuck transmitting at the lowest rate allowed by the rate mask. This is because the firmware doesn't know the device is connected to a network. Fix the macros SET_H2CCMD_MSRRPT_PARM_OPMODE and SET_H2CCMD_MSRRPT_PARM_MACID_IND to work on the first byte of __cmd, not the second. Now the firmware is correctly notified when the device is connected to a network and it activates the rate control. Before (MCS3): [ 5] 0.00-1.00 sec 12.5 MBytes 105 Mbits/sec 0 339 KBytes [ 5] 1.00-2.00 sec 10.6 MBytes 89.1 Mbits/sec 0 339 KBytes [ 5] 2.00-3.00 sec 10.6 MBytes 89.1 Mbits/sec 0 386 KBytes [ 5] 3.00-4.00 sec 10.6 MBytes 89.1 Mbits/sec 0 386 KBytes [ 5] 4.00-5.00 sec 10.2 MBytes 86.0 Mbits/sec 0 427 KBytes After (MCS9): [ 5] 0.00-1.00 sec 33.9 MBytes 284 Mbits/sec 0 771 KBytes [ 5] 1.00-2.00 sec 31.6 MBytes 265 Mbits/sec 0 865 KBytes [ 5] 2.00-3.00 sec 29.9 MBytes 251 Mbits/sec 0 963 KBytes [ 5] 3.00-4.00 sec 28.2 MBytes 237 Mbits/sec 0 963 KBytes [ 5] 4.00-5.00 sec 26.8 MBytes 224 Mbits/sec 0 963 KBytes Fixes: 39f40710d0b5 ("rtlwifi: rtl88821ae: Remove usage of private bit manipulation macros") Cc: [email protected] Signed-off-by: Bitterblue Smith <[email protected]> Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Fiona Klute <[email protected]> Date: Mon Jan 6 15:54:34 2025 +0200 wifi: rtw88: sdio: Fix disconnection after beacon loss commit fb2fcfbe5eef9ae26b0425978435ae1308951e51 upstream. This is the equivalent of commit 28818b4d871b ("wifi: rtw88: usb: Fix disconnection after beacon loss") for SDIO chips. Tested on Pinephone (RTL8723CS), random disconnections became rare, instead of a frequent nuisance. Cc: [email protected] Signed-off-by: Fiona Klute <[email protected]> Tested-by: Vasily Khoruzhick <[email protected]> # Tested on Pinebook Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chih-Kang Chang <[email protected]> Date: Thu Nov 28 13:54:33 2024 +0800 wifi: rtw89: add crystal_cap check to avoid setting as overflow value [ Upstream commit 7b98caea39676561f22db58752551161bb36462b ] In the original flow, the crystal_cap might be calculated as a negative value and set as an overflow value. Therefore, we added a check to limit the calculated crystal_cap value. Additionally, we shrank the crystal_cap adjustment according to specific CFO. Signed-off-by: Chih-Kang Chang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Yazen Ghannam <[email protected]> Date: Fri Dec 6 16:11:55 2024 +0000 x86/amd_nb: Restrict init function to AMD-based systems [ Upstream commit bee9e840609cc67d0a7d82f22a2130fb7a0a766d ] The code implicitly operates on AMD-based systems by matching on PCI IDs. However, the use of these IDs is going away. Add an explicit CPU vendor check instead of relying on PCI IDs. Signed-off-by: Yazen Ghannam <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Tue Jan 21 18:11:33 2025 -0700 x86/boot: Use '-std=gnu11' to fix build with GCC 15 commit ee2ab467bddfb2d7f68d996dbab94d7b88f8eaf7 upstream. GCC 15 changed the default C standard version to C23, which should not have impacted the kernel because it requests the gnu11 standard via '-std=' in the main Makefile. However, the x86 compressed boot Makefile uses its own set of KBUILD_CFLAGS without a '-std=' value (i.e., using the default), resulting in errors from the kernel's definitions of bool, true, and false in stddef.h, which are reserved keywords under C23. ./include/linux/stddef.h:11:9: error: expected identifier before ‘false’ 11 | false = 0, ./include/linux/types.h:35:33: error: two or more data types in declaration specifiers 35 | typedef _Bool bool; Set '-std=gnu11' in the x86 compressed boot Makefile to resolve the error and consistently use the same C standard version for the entire kernel. Closes: https://lore.kernel.org/4OAhbllK7x4QJGpZjkYjtBYNLd_2whHx9oFiuZcGwtVR4hIzvduultkgfAIRZI3vQpZylu7Gl929HaYFRGeMEalWCpeMzCIIhLxxRhq4U-Y=@protonmail.com/ Closes: https://lore.kernel.org/Z4467umXR2PZ0M1H@tucnak/ Reported-by: Kostadin Shishmanov <[email protected]> Reported-by: Jakub Jelinek <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Cc:[email protected] Link: https://lore.kernel.org/all/20250121-x86-use-std-consistently-gcc-15-v1-1-8ab0acf645cb%40kernel.org Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Woodhouse <[email protected]> Date: Thu Dec 5 15:05:11 2024 +0000 x86/kexec: Allocate PGD for x86_64 transition page tables separately [ Upstream commit 4b5bc2ec9a239bce261ffeafdd63571134102323 ] Now that the following fix: d0ceea662d45 ("x86/mm: Add _PAGE_NOPTISHADOW bit to avoid updating userspace page tables") stops kernel_ident_mapping_init() from scribbling over the end of a 4KiB PGD by assuming the following 4KiB will be a userspace PGD, there's no good reason for the kexec PGD to be part of a single 8KiB allocation with the control_code_page. ( It's not clear that that was the reason for x86_64 kexec doing it that way in the first place either; there were no comments to that effect and it seems to have been the case even before PTI came along. It looks like it was just a happy accident which prevented memory corruption on kexec. ) Either way, it definitely isn't needed now. Just allocate the PGD separately on x86_64, like i386 already does. Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: Baoquan He <[email protected]> Cc: Vivek Goyal <[email protected]> Cc: Dave Young <[email protected]> Cc: Eric Biederman <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Steve Wahl <[email protected]> Date: Wed Jul 17 16:31:21 2024 -0500 x86/mm/ident_map: Use gbpages only where full GB page should be mapped. commit cc31744a294584a36bf764a0ffa3255a8e69f036 upstream. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence. Signed-off-by: Steve Wahl <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Pavin Joseph <[email protected]> Tested-by: Sarah Brofeldt <[email protected]> Tested-by: Eric Hagberg <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Juergen Gross <[email protected]> Date: Wed Feb 5 10:07:56 2025 +0100 x86/xen: add FRAME_END to xen_hypercall_hvm() [ Upstream commit 0bd797b801bd8ee06c822844e20d73aaea0878dd ] xen_hypercall_hvm() is missing a FRAME_END at the end, add it. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: b4845bb63838 ("x86/xen: add central hypercall functions") Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Jan Beulich <[email protected]> Reviewed-by: Andrew Cooper <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Juergen Gross <[email protected]> Date: Wed Feb 5 09:43:31 2025 +0100 x86/xen: fix xen_hypercall_hvm() to not clobber %rbx [ Upstream commit 98a5cfd2320966f40fe049a9855f8787f0126825 ] xen_hypercall_hvm(), which is used when running as a Xen PVH guest at most only once during early boot, is clobbering %rbx. Depending on whether the caller relies on %rbx to be preserved across the call or not, this clobbering might result in an early crash of the system. This can be avoided by using an already saved register instead of %rbx. Fixes: b4845bb63838 ("x86/xen: add central hypercall functions") Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Jan Beulich <[email protected]> Reviewed-by: Andrew Cooper <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wentao Liang <[email protected]> Date: Fri Jan 24 11:45:09 2025 +0800 xfs: Add error handling for xfs_reflink_cancel_cow_range commit 26b63bee2f6e711c5a169997fd126fddcfb90848 upstream. In xfs_inactive(), xfs_reflink_cancel_cow_range() is called without error handling, risking unnoticed failures and inconsistent behavior compared to other parts of the code. Fix this issue by adding an error handling for the xfs_reflink_cancel_cow_range(), improving code robustness. Fixes: 6231848c3aa5 ("xfs: check for cow blocks before trying to clear them") Cc: [email protected] # v4.17 Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Wentao Liang <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wentao Liang <[email protected]> Date: Fri Jan 24 11:22:28 2025 +0800 xfs: Propagate errors from xfs_reflink_cancel_cow_range in xfs_dax_write_iomap_end commit fb95897b8c60653805aa09daec575ca30983f768 upstream. In xfs_dax_write_iomap_end(), directly return the result of xfs_reflink_cancel_cow_range() when !written, ensuring proper error propagation and improving code robustness. Fixes: ea6c49b784f0 ("xfs: support CoW in fsdax mode") Cc: [email protected] # v6.0 Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Wentao Liang <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>