June 2025 - Linux-stable-mirror

FAILED: patch "[PATCH] arm64: dts: rockchip: fix internal USB hub instability on" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x d7cc532df95f7f159e40595440e4e4b99481457b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060235-unroll-candy-0261@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d7cc532df95f7f159e40595440e4e4b99481457b Mon Sep 17 00:00:00 2001 From: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Date: Fri, 25 Apr 2025 17:18:08 +0200 Subject: [PATCH] arm64: dts: rockchip: fix internal USB hub instability on RK3399 Puma MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently, the onboard Cypress CYUSB3304 USB hub is not defined in the device tree, and hub reset pin is provided as vcc5v0_host regulator to usb phy. This causes instability issues, as a result of improper reset duration. The fixed regulator device requests the GPIO during probe in its inactive state (except if regulator-boot-on property is set, in which case it is requested in the active state). Considering gpio is GPIO_ACTIVE_LOW for Puma, it means it’s driving it high. Then the regulator gets enabled (because regulator-always-on property), which drives it to its active state, meaning driving it low. The Cypress CYUSB3304 USB hub actually requires the reset to be asserted for at least 5 ms, which we cannot guarantee right now since there's no delay in the current config, meaning the hub may sometimes work or not. We could add delay as offered by fixed-regulator but let's rather fix this by using the proper way to model onboard USB hubs. Define hub_2_0 and hub_3_0 nodes, as the onboard Cypress hub consist of two 'logical' hubs, for USB2.0 and USB3.0. Use the 'reset-gpios' property of hub to assign reset pin instead of using regulator. Rename the vcc5v0_host regulator to cy3304_reset to be more meaningful. Pin is configured to output-high by default, which sets the hub in reset state during pin controller initialization. This allows to avoid double enumeration of devices in case the bootloader has setup the USB hub before the kernel. The vdd-supply and vdd2-supply properties in hub nodes are added to provide correct dt-bindings, although power supplies are always enabled based on HW design. Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Cc: stable(a)vger.kernel.org # 6.6 Cc: stable(a)vger.kernel.org # Backport of the patch in this series fixing product ID in onboard_dev_id_table in drivers/usb/misc/onboard_usb_dev.c driver Signed-off-by: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-3-4a76a474a010@thauma… Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi index e00fbaa8acc1..314d9dfdba57 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi @@ -60,16 +60,6 @@ vcc3v3_sys: regulator-vcc3v3-sys { vin-supply = <&vcc5v0_sys>; }; - vcc5v0_host: regulator-vcc5v0-host { - compatible = "regulator-fixed"; - gpio = <&gpio4 RK_PA3 GPIO_ACTIVE_LOW>; - pinctrl-names = "default"; - pinctrl-0 = <&vcc5v0_host_en>; - regulator-name = "vcc5v0_host"; - regulator-always-on; - vin-supply = <&vcc5v0_sys>; - }; - vcc5v0_sys: regulator-vcc5v0-sys { compatible = "regulator-fixed"; regulator-name = "vcc5v0_sys"; @@ -527,10 +517,10 @@ pmic_int_l: pmic-int-l { }; }; - usb2 { - vcc5v0_host_en: vcc5v0-host-en { + usb { + cy3304_reset: cy3304-reset { rockchip,pins = - <4 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>; + <4 RK_PA3 RK_FUNC_GPIO &pcfg_output_high>; }; }; @@ -597,7 +587,6 @@ u2phy1_otg: otg-port { }; u2phy1_host: host-port { - phy-supply = <&vcc5v0_host>; status = "okay"; }; }; @@ -609,6 +598,29 @@ &usbdrd3_1 { &usbdrd_dwc3_1 { status = "okay"; dr_mode = "host"; + pinctrl-names = "default"; + pinctrl-0 = <&cy3304_reset>; + #address-cells = <1>; + #size-cells = <0>; + + hub_2_0: hub@1 { + compatible = "usb4b4,6502", "usb4b4,6506"; + reg = <1>; + peer-hub = <&hub_3_0>; + reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>; + vdd-supply = <&vcc1v2_phy>; + vdd2-supply = <&vcc3v3_sys>; + + }; + + hub_3_0: hub@2 { + compatible = "usb4b4,6500", "usb4b4,6504"; + reg = <2>; + peer-hub = <&hub_2_0>; + reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>; + vdd-supply = <&vcc1v2_phy>; + vdd2-supply = <&vcc3v3_sys>; + }; }; &usb_host1_ehci {

3 weeks, 2 days

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: rockchip: fix internal USB hub instability on" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x d7cc532df95f7f159e40595440e4e4b99481457b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060233-umpire-askew-5f0b@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d7cc532df95f7f159e40595440e4e4b99481457b Mon Sep 17 00:00:00 2001 From: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Date: Fri, 25 Apr 2025 17:18:08 +0200 Subject: [PATCH] arm64: dts: rockchip: fix internal USB hub instability on RK3399 Puma MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently, the onboard Cypress CYUSB3304 USB hub is not defined in the device tree, and hub reset pin is provided as vcc5v0_host regulator to usb phy. This causes instability issues, as a result of improper reset duration. The fixed regulator device requests the GPIO during probe in its inactive state (except if regulator-boot-on property is set, in which case it is requested in the active state). Considering gpio is GPIO_ACTIVE_LOW for Puma, it means it’s driving it high. Then the regulator gets enabled (because regulator-always-on property), which drives it to its active state, meaning driving it low. The Cypress CYUSB3304 USB hub actually requires the reset to be asserted for at least 5 ms, which we cannot guarantee right now since there's no delay in the current config, meaning the hub may sometimes work or not. We could add delay as offered by fixed-regulator but let's rather fix this by using the proper way to model onboard USB hubs. Define hub_2_0 and hub_3_0 nodes, as the onboard Cypress hub consist of two 'logical' hubs, for USB2.0 and USB3.0. Use the 'reset-gpios' property of hub to assign reset pin instead of using regulator. Rename the vcc5v0_host regulator to cy3304_reset to be more meaningful. Pin is configured to output-high by default, which sets the hub in reset state during pin controller initialization. This allows to avoid double enumeration of devices in case the bootloader has setup the USB hub before the kernel. The vdd-supply and vdd2-supply properties in hub nodes are added to provide correct dt-bindings, although power supplies are always enabled based on HW design. Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Cc: stable(a)vger.kernel.org # 6.6 Cc: stable(a)vger.kernel.org # Backport of the patch in this series fixing product ID in onboard_dev_id_table in drivers/usb/misc/onboard_usb_dev.c driver Signed-off-by: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-3-4a76a474a010@thauma… Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi index e00fbaa8acc1..314d9dfdba57 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi @@ -60,16 +60,6 @@ vcc3v3_sys: regulator-vcc3v3-sys { vin-supply = <&vcc5v0_sys>; }; - vcc5v0_host: regulator-vcc5v0-host { - compatible = "regulator-fixed"; - gpio = <&gpio4 RK_PA3 GPIO_ACTIVE_LOW>; - pinctrl-names = "default"; - pinctrl-0 = <&vcc5v0_host_en>; - regulator-name = "vcc5v0_host"; - regulator-always-on; - vin-supply = <&vcc5v0_sys>; - }; - vcc5v0_sys: regulator-vcc5v0-sys { compatible = "regulator-fixed"; regulator-name = "vcc5v0_sys"; @@ -527,10 +517,10 @@ pmic_int_l: pmic-int-l { }; }; - usb2 { - vcc5v0_host_en: vcc5v0-host-en { + usb { + cy3304_reset: cy3304-reset { rockchip,pins = - <4 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>; + <4 RK_PA3 RK_FUNC_GPIO &pcfg_output_high>; }; }; @@ -597,7 +587,6 @@ u2phy1_otg: otg-port { }; u2phy1_host: host-port { - phy-supply = <&vcc5v0_host>; status = "okay"; }; }; @@ -609,6 +598,29 @@ &usbdrd3_1 { &usbdrd_dwc3_1 { status = "okay"; dr_mode = "host"; + pinctrl-names = "default"; + pinctrl-0 = <&cy3304_reset>; + #address-cells = <1>; + #size-cells = <0>; + + hub_2_0: hub@1 { + compatible = "usb4b4,6502", "usb4b4,6506"; + reg = <1>; + peer-hub = <&hub_3_0>; + reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>; + vdd-supply = <&vcc1v2_phy>; + vdd2-supply = <&vcc3v3_sys>; + + }; + + hub_3_0: hub@2 { + compatible = "usb4b4,6500", "usb4b4,6504"; + reg = <2>; + peer-hub = <&hub_2_0>; + reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>; + vdd-supply = <&vcc1v2_phy>; + vdd2-supply = <&vcc3v3_sys>; + }; }; &usb_host1_ehci {

3 weeks, 2 days

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: rockchip: fix internal USB hub instability on" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x d7cc532df95f7f159e40595440e4e4b99481457b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060232-saga-chatty-ea5b@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d7cc532df95f7f159e40595440e4e4b99481457b Mon Sep 17 00:00:00 2001 From: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Date: Fri, 25 Apr 2025 17:18:08 +0200 Subject: [PATCH] arm64: dts: rockchip: fix internal USB hub instability on RK3399 Puma MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently, the onboard Cypress CYUSB3304 USB hub is not defined in the device tree, and hub reset pin is provided as vcc5v0_host regulator to usb phy. This causes instability issues, as a result of improper reset duration. The fixed regulator device requests the GPIO during probe in its inactive state (except if regulator-boot-on property is set, in which case it is requested in the active state). Considering gpio is GPIO_ACTIVE_LOW for Puma, it means it’s driving it high. Then the regulator gets enabled (because regulator-always-on property), which drives it to its active state, meaning driving it low. The Cypress CYUSB3304 USB hub actually requires the reset to be asserted for at least 5 ms, which we cannot guarantee right now since there's no delay in the current config, meaning the hub may sometimes work or not. We could add delay as offered by fixed-regulator but let's rather fix this by using the proper way to model onboard USB hubs. Define hub_2_0 and hub_3_0 nodes, as the onboard Cypress hub consist of two 'logical' hubs, for USB2.0 and USB3.0. Use the 'reset-gpios' property of hub to assign reset pin instead of using regulator. Rename the vcc5v0_host regulator to cy3304_reset to be more meaningful. Pin is configured to output-high by default, which sets the hub in reset state during pin controller initialization. This allows to avoid double enumeration of devices in case the bootloader has setup the USB hub before the kernel. The vdd-supply and vdd2-supply properties in hub nodes are added to provide correct dt-bindings, although power supplies are always enabled based on HW design. Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Cc: stable(a)vger.kernel.org # 6.6 Cc: stable(a)vger.kernel.org # Backport of the patch in this series fixing product ID in onboard_dev_id_table in drivers/usb/misc/onboard_usb_dev.c driver Signed-off-by: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-3-4a76a474a010@thauma… Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi index e00fbaa8acc1..314d9dfdba57 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi @@ -60,16 +60,6 @@ vcc3v3_sys: regulator-vcc3v3-sys { vin-supply = <&vcc5v0_sys>; }; - vcc5v0_host: regulator-vcc5v0-host { - compatible = "regulator-fixed"; - gpio = <&gpio4 RK_PA3 GPIO_ACTIVE_LOW>; - pinctrl-names = "default"; - pinctrl-0 = <&vcc5v0_host_en>; - regulator-name = "vcc5v0_host"; - regulator-always-on; - vin-supply = <&vcc5v0_sys>; - }; - vcc5v0_sys: regulator-vcc5v0-sys { compatible = "regulator-fixed"; regulator-name = "vcc5v0_sys"; @@ -527,10 +517,10 @@ pmic_int_l: pmic-int-l { }; }; - usb2 { - vcc5v0_host_en: vcc5v0-host-en { + usb { + cy3304_reset: cy3304-reset { rockchip,pins = - <4 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>; + <4 RK_PA3 RK_FUNC_GPIO &pcfg_output_high>; }; }; @@ -597,7 +587,6 @@ u2phy1_otg: otg-port { }; u2phy1_host: host-port { - phy-supply = <&vcc5v0_host>; status = "okay"; }; }; @@ -609,6 +598,29 @@ &usbdrd3_1 { &usbdrd_dwc3_1 { status = "okay"; dr_mode = "host"; + pinctrl-names = "default"; + pinctrl-0 = <&cy3304_reset>; + #address-cells = <1>; + #size-cells = <0>; + + hub_2_0: hub@1 { + compatible = "usb4b4,6502", "usb4b4,6506"; + reg = <1>; + peer-hub = <&hub_3_0>; + reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>; + vdd-supply = <&vcc1v2_phy>; + vdd2-supply = <&vcc3v3_sys>; + + }; + + hub_3_0: hub@2 { + compatible = "usb4b4,6500", "usb4b4,6504"; + reg = <2>; + peer-hub = <&hub_2_0>; + reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>; + vdd-supply = <&vcc1v2_phy>; + vdd2-supply = <&vcc3v3_sys>; + }; }; &usb_host1_ehci {

3 weeks, 2 days

1
0
0 0

[PATCH 6.1.y v2] selftests/vm: fix split huge page tests

by Guangming Wang

From: Zi Yan <ziy(a)nvidia.com> [ upstream commit dd63bd7df41a8f9393a2e3ff9157a441c08eb996 ] Fix two inputs to check_anon_huge() and one if condition, so the tests work as expected. Steps to reproduce the issue. make headers make -C tools/testing/selftests/vm Before patching:test fails with a non-zero exit code ~/linux$ sudo tools/testing/selftests/vm/split_huge_page_test \ > /dev/null 2>&1;echo $? 1 ~/linux$ ./split_huge_page_test No THP is allocated After patching: ~/linux$ sudo tools/testing/selftests/vm/split_huge_page_test \ > /dev/null 2>&1;echo $? 0 ~/linux$ sudo tools/testing/selftests/vm/split_huge_page_test Split huge pages successful ... Link: https://lkml.kernel.org/r/20230306160907.16804-1-zi.yan@sent.com Fixes: c07c343cda8e ("selftests/vm: dedup THP helpers") Cc: stable(a)vger.kernel.org Signed-off-by: Zi Yan <ziy(a)nvidia.com> Reviewed-by: Zach O'Keefe <zokeefe(a)google.com> Tested-by: Zach O'Keefe <zokeefe(a)google.com> Acked-by: David Hildenbrand <david(a)redhat.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Guangming Wang <guangming.wang(a)windriver.com> --- tools/testing/selftests/vm/split_huge_page_test.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/vm/split_huge_page_test.c b/tools/testing/selftests/vm/split_huge_page_test.c index 76e1c36dd..b8558c7f1 100644 --- a/tools/testing/selftests/vm/split_huge_page_test.c +++ b/tools/testing/selftests/vm/split_huge_page_test.c @@ -106,7 +106,7 @@ void split_pmd_thp(void) for (i = 0; i < len; i++) one_page[i] = (char)i; - if (!check_huge_anon(one_page, 1, pmd_pagesize)) { + if (!check_huge_anon(one_page, 4, pmd_pagesize)) { printf("No THP is allocated\n"); exit(EXIT_FAILURE); } @@ -122,7 +122,7 @@ void split_pmd_thp(void) } - if (check_huge_anon(one_page, 0, pmd_pagesize)) { + if (!check_huge_anon(one_page, 0, pmd_pagesize)) { printf("Still AnonHugePages not split\n"); exit(EXIT_FAILURE); } @@ -169,7 +169,7 @@ void split_pte_mapped_thp(void) for (i = 0; i < len; i++) one_page[i] = (char)i; - if (!check_huge_anon(one_page, 1, pmd_pagesize)) { + if (!check_huge_anon(one_page, 4, pmd_pagesize)) { printf("No THP is allocated\n"); exit(EXIT_FAILURE); } -- 2.34.1

3 weeks, 2 days

3
2
0 0

[PATCH v2] mm: userfaultfd: fix race of userfaultfd_move and swap cache

by Kairui Song

From: Kairui Song <kasong(a)tencent.com> On seeing a swap entry PTE, userfaultfd_move does a lockless swap cache lookup, and try to move the found folio to the faulting vma when. Currently, it relies on the PTE value check to ensure the moved folio still belongs to the src swap entry, which turns out is not reliable. While working and reviewing the swap table series with Barry, following existing race is observed and reproduced [1]: ( move_pages_pte is moving src_pte to dst_pte, where src_pte is a swap entry PTE holding swap entry S1, and S1 isn't in the swap cache.) CPU1 CPU2 userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // Here it got entry = S1 ... < Somehow interrupted> ... <swapin src_pte, alloc and use folio A> // folio A is just a new allocated folio // and get installed into src_pte <frees swap entry S1> // src_pte now points to folio A, S1 // has swap count == 0, it can be freed // by folio_swap_swap or swap // allocator's reclaim. <try to swap out another folio B> // folio B is a folio in another VMA. <put folio B to swap cache using S1 > // S1 is freed, folio B could use it // for swap out with no problem. ... folio = filemap_get_folio(S1) // Got folio B here !!! ... < Somehow interrupted again> ... <swapin folio B and free S1> // Now S1 is free to be used again. <swapout src_pte & folio A using S1> // Now src_pte is a swap entry pte // holding S1 again. folio_trylock(folio) move_swap_pte double_pt_lock is_pte_pages_stable // Check passed because src_pte == S1 folio_move_anon_rmap(...) // Moved invalid folio B here !!! The race window is very short and requires multiple collisions of multiple rare events, so it's very unlikely to happen, but with a deliberately constructed reproducer and increased time window, it can be reproduced [1]. It's also possible that folio (A) is swapped in, and swapped out again after the filemap_get_folio lookup, in such case folio (A) may stay in swap cache so it needs to be moved too. In this case we should also try again so kernel won't miss a folio move. Fix this by checking if the folio is the valid swap cache folio after acquiring the folio lock, and checking the swap cache again after acquiring the src_pte lock. SWP_SYNCRHONIZE_IO path does make the problem more complex, but so far we don't need to worry about that since folios only might get exposed to swap cache in the swap out path, and it's covered in this patch too by checking the swap cache again after acquiring src_pte lock. Testing with a simple C program to allocate and move several GB of memory did not show any observable performance change. Cc: <stable(a)vger.kernel.org> Fixes: adef440691ba ("userfaultfd: UFFDIO_MOVE uABI") Closes: https://lore.kernel.org/linux-mm/CAMgjq7B1K=6OOrK2OUZ0-tqCzi+EJt+2_K97TPGoS… [1] Signed-off-by: Kairui Song <kasong(a)tencent.com> --- V1: https://lore.kernel.org/linux-mm/20250530201710.81365-1-ryncsn@gmail.com/ Changes: - Check swap_map instead of doing a filemap lookup after acquiring the PTE lock to minimize critical section overhead [ Barry Song, Lokesh Gidra ] mm/userfaultfd.c | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c index bc473ad21202..a74ede04996c 100644 --- a/mm/userfaultfd.c +++ b/mm/userfaultfd.c @@ -1084,8 +1084,11 @@ static int move_swap_pte(struct mm_struct *mm, struct vm_area_struct *dst_vma, pte_t orig_dst_pte, pte_t orig_src_pte, pmd_t *dst_pmd, pmd_t dst_pmdval, spinlock_t *dst_ptl, spinlock_t *src_ptl, - struct folio *src_folio) + struct folio *src_folio, + struct swap_info_struct *si) { + swp_entry_t entry; + double_pt_lock(dst_ptl, src_ptl); if (!is_pte_pages_stable(dst_pte, src_pte, orig_dst_pte, orig_src_pte, @@ -1102,6 +1105,16 @@ static int move_swap_pte(struct mm_struct *mm, struct vm_area_struct *dst_vma, if (src_folio) { folio_move_anon_rmap(src_folio, dst_vma); src_folio->index = linear_page_index(dst_vma, dst_addr); + } else { + /* + * Check if the swap entry is cached after acquiring the src_pte + * lock. Or we might miss a new loaded swap cache folio. + */ + entry = pte_to_swp_entry(orig_src_pte); + if (si->swap_map[swp_offset(entry)] & SWAP_HAS_CACHE) { + double_pt_unlock(dst_ptl, src_ptl); + return -EAGAIN; + } } orig_src_pte = ptep_get_and_clear(mm, src_addr, src_pte); @@ -1409,10 +1422,20 @@ static int move_pages_pte(struct mm_struct *mm, pmd_t *dst_pmd, pmd_t *src_pmd, folio_lock(src_folio); goto retry; } + /* + * Check if the folio still belongs to the target swap entry after + * acquiring the lock. Folio can be freed in the swap cache while + * not locked. + */ + if (unlikely(!folio_test_swapcache(folio) || + entry.val != folio->swap.val)) { + err = -EAGAIN; + goto out; + } } err = move_swap_pte(mm, dst_vma, dst_addr, src_addr, dst_pte, src_pte, orig_dst_pte, orig_src_pte, dst_pmd, dst_pmdval, - dst_ptl, src_ptl, src_folio); + dst_ptl, src_ptl, src_folio, si); } out: -- 2.49.0

3 weeks, 2 days

3
3
0 0

[PATCH] mm: Fix vmstat after removing NR_BOUNCE

by Kirill A. Shutemov

Hongyu noticed that the nr_unaccepted counter kept growing even in the absence of unaccepted memory on the machine. This happens due to a commit that removed NR_BOUNCE: it removed the counter from the enum zone_stat_item, but left it in the vmstat_text array. As a result, all counters below nr_bounce in /proc/vmstat are shifted by one line, causing the numa_hit counter to be labeled as nr_unaccepted. To fix this issue, remove nr_bounce from the vmstat_text array. Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Reported-by: Hongyu Ning <hongyu.ning(a)linux.intel.com> Fixes: 194df9f66db8 ("mm: remove NR_BOUNCE zone stat") Cc: stable(a)vger.kernel.org Cc: Christoph Hellwig <hch(a)lst.de> Cc: Hannes Reinecke <hare(a)suse.de> Cc: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> Cc: Jens Axboe <axboe(a)kernel.dk> --- mm/vmstat.c | 1 - 1 file changed, 1 deletion(-) diff --git a/mm/vmstat.c b/mm/vmstat.c index 4c268ce39ff2..ae9882063d89 100644 --- a/mm/vmstat.c +++ b/mm/vmstat.c @@ -1201,7 +1201,6 @@ const char * const vmstat_text[] = { "nr_zone_unevictable", "nr_zone_write_pending", "nr_mlock", - "nr_bounce", #if IS_ENABLED(CONFIG_ZSMALLOC) "nr_zspages", #endif -- 2.47.2

3 weeks, 2 days

8
11
0 0

Re: [PATCH v4] virtio_blk: Fix disk deletion hang on device surprise removal

by ALOK TIWARI

On 31-05-2025 11:03, Parav Pandit wrote: > + if (!virtqueue_is_broken(vblk->vqs[0].vq)) is it call, if the virtqueue is not broken ? > + virtblk_cleanup_broken_device(vblk); > + > del_gendisk(vblk->disk); > blk_mq_free_tag_set(&vblk->tag_set); Thanks, Alok

3 weeks, 2 days

2
1
0 0

[PATCH AUTOSEL 5.4 01/22] drm/amdgpu/gfx6: fix CSIB handling

by Sasha Levin

From: Alex Deucher <alexander.deucher(a)amd.com> [ Upstream commit 8307ebc15c1ea98a8a0b7837af1faa6c01514577 ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira <siqueira(a)igalia.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Now let me understand what the bug is. Looking at the original code: ```c for (sect = adev->gfx.rlc.cs_data; sect->section != NULL; ++sect) { for (ext = sect->section; ext->extent != NULL; ++ext) { if (sect->id == SECT_CONTEXT) { // process SECT_CONTEXT sections } else { return; // BUG: This returns early, skipping remaining code } } } // Important code that should always run: buffer[count++] = cpu_to_le32(PACKET3(PACKET3_SET_CONTEXT_REG, 1)); buffer[count++] = cpu_to_le32(mmPA_SC_RASTER_CONFIG - PACKET3_SET_CONTEXT_REG_START); // ... more important buffer initialization ``` The fix removes the early return so that all sections are processed and the important buffer initialization at the end always runs. **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Clear Bug Fix**: The commit fixes a clear logic error where an early return statement prevents critical buffer initialization code from executing. The original code would return immediately when encountering a non- SECT_CONTEXT section, skipping the important packet commands that should always be written to the buffer (PACKET3_SET_CONTEXT_REG, PACKET3_PREAMBLE_END_CLEAR_STATE, PACKET3_CLEAR_STATE). 2. **Functional Impact**: This bug affects the Clear State Indirect Buffer (CSIB) handling in AMD GPU driver for GFX6 hardware. The incomplete buffer initialization could lead to: - Incorrect GPU state during graphics operations - Potential rendering issues or GPU hangs - Inconsistent hardware behavior 3. **Small and Contained Fix**: The fix is minimal - it simply removes two lines (the else block with return statement). This is a low-risk change that doesn't introduce new functionality or alter the architecture. 4. **Hardware-Specific Bug**: This affects real users with GFX6 AMD GPUs. The bug prevents proper initialization of the GPU's clear state buffer, which is essential for correct GPU operation. 5. **Similar to Historical Backports**: Looking at commit 4 in the similar commits (marked as YES for backporting), which also fixed preamble handling issues in the AMD GPU driver, this follows a similar pattern of fixing command buffer handling bugs. The commit message clearly indicates this is a bug fix ("We shouldn't return after the last section. We need to update the rest of the CSIB"), and the code change confirms that critical buffer initialization was being skipped due to the premature return. drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c index 7f0a63628c43a..eac329fe27902 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c @@ -2901,8 +2901,6 @@ static void gfx_v6_0_get_csb_buffer(struct amdgpu_device *adev, buffer[count++] = cpu_to_le32(ext->reg_index - 0xa000); for (i = 0; i < ext->reg_count; i++) buffer[count++] = cpu_to_le32(ext->extent[i]); - } else { - return; } } } -- 2.39.5

3 weeks, 2 days

1
21
0 0

[PATCH AUTOSEL 5.10 01/34] drm/amdgpu/gfx6: fix CSIB handling

by Sasha Levin

From: Alex Deucher <alexander.deucher(a)amd.com> [ Upstream commit 8307ebc15c1ea98a8a0b7837af1faa6c01514577 ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira <siqueira(a)igalia.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Now let me understand what the bug is. Looking at the original code: ```c for (sect = adev->gfx.rlc.cs_data; sect->section != NULL; ++sect) { for (ext = sect->section; ext->extent != NULL; ++ext) { if (sect->id == SECT_CONTEXT) { // process SECT_CONTEXT sections } else { return; // BUG: This returns early, skipping remaining code } } } // Important code that should always run: buffer[count++] = cpu_to_le32(PACKET3(PACKET3_SET_CONTEXT_REG, 1)); buffer[count++] = cpu_to_le32(mmPA_SC_RASTER_CONFIG - PACKET3_SET_CONTEXT_REG_START); // ... more important buffer initialization ``` The fix removes the early return so that all sections are processed and the important buffer initialization at the end always runs. **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Clear Bug Fix**: The commit fixes a clear logic error where an early return statement prevents critical buffer initialization code from executing. The original code would return immediately when encountering a non- SECT_CONTEXT section, skipping the important packet commands that should always be written to the buffer (PACKET3_SET_CONTEXT_REG, PACKET3_PREAMBLE_END_CLEAR_STATE, PACKET3_CLEAR_STATE). 2. **Functional Impact**: This bug affects the Clear State Indirect Buffer (CSIB) handling in AMD GPU driver for GFX6 hardware. The incomplete buffer initialization could lead to: - Incorrect GPU state during graphics operations - Potential rendering issues or GPU hangs - Inconsistent hardware behavior 3. **Small and Contained Fix**: The fix is minimal - it simply removes two lines (the else block with return statement). This is a low-risk change that doesn't introduce new functionality or alter the architecture. 4. **Hardware-Specific Bug**: This affects real users with GFX6 AMD GPUs. The bug prevents proper initialization of the GPU's clear state buffer, which is essential for correct GPU operation. 5. **Similar to Historical Backports**: Looking at commit 4 in the similar commits (marked as YES for backporting), which also fixed preamble handling issues in the AMD GPU driver, this follows a similar pattern of fixing command buffer handling bugs. The commit message clearly indicates this is a bug fix ("We shouldn't return after the last section. We need to update the rest of the CSIB"), and the code change confirms that critical buffer initialization was being skipped due to the premature return. drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c index 79c52c7a02e3a..d447b2416b98b 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c @@ -2896,8 +2896,6 @@ static void gfx_v6_0_get_csb_buffer(struct amdgpu_device *adev, buffer[count++] = cpu_to_le32(ext->reg_index - 0xa000); for (i = 0; i < ext->reg_count; i++) buffer[count++] = cpu_to_le32(ext->extent[i]); - } else { - return; } } } -- 2.39.5

3 weeks, 2 days

1
33
0 0

[PATCH AUTOSEL 5.15 01/43] drm/amdgpu/gfx6: fix CSIB handling

by Sasha Levin

From: Alex Deucher <alexander.deucher(a)amd.com> [ Upstream commit 8307ebc15c1ea98a8a0b7837af1faa6c01514577 ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira <siqueira(a)igalia.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Now let me understand what the bug is. Looking at the original code: ```c for (sect = adev->gfx.rlc.cs_data; sect->section != NULL; ++sect) { for (ext = sect->section; ext->extent != NULL; ++ext) { if (sect->id == SECT_CONTEXT) { // process SECT_CONTEXT sections } else { return; // BUG: This returns early, skipping remaining code } } } // Important code that should always run: buffer[count++] = cpu_to_le32(PACKET3(PACKET3_SET_CONTEXT_REG, 1)); buffer[count++] = cpu_to_le32(mmPA_SC_RASTER_CONFIG - PACKET3_SET_CONTEXT_REG_START); // ... more important buffer initialization ``` The fix removes the early return so that all sections are processed and the important buffer initialization at the end always runs. **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Clear Bug Fix**: The commit fixes a clear logic error where an early return statement prevents critical buffer initialization code from executing. The original code would return immediately when encountering a non- SECT_CONTEXT section, skipping the important packet commands that should always be written to the buffer (PACKET3_SET_CONTEXT_REG, PACKET3_PREAMBLE_END_CLEAR_STATE, PACKET3_CLEAR_STATE). 2. **Functional Impact**: This bug affects the Clear State Indirect Buffer (CSIB) handling in AMD GPU driver for GFX6 hardware. The incomplete buffer initialization could lead to: - Incorrect GPU state during graphics operations - Potential rendering issues or GPU hangs - Inconsistent hardware behavior 3. **Small and Contained Fix**: The fix is minimal - it simply removes two lines (the else block with return statement). This is a low-risk change that doesn't introduce new functionality or alter the architecture. 4. **Hardware-Specific Bug**: This affects real users with GFX6 AMD GPUs. The bug prevents proper initialization of the GPU's clear state buffer, which is essential for correct GPU operation. 5. **Similar to Historical Backports**: Looking at commit 4 in the similar commits (marked as YES for backporting), which also fixed preamble handling issues in the AMD GPU driver, this follows a similar pattern of fixing command buffer handling bugs. The commit message clearly indicates this is a bug fix ("We shouldn't return after the last section. We need to update the rest of the CSIB"), and the code change confirms that critical buffer initialization was being skipped due to the premature return. drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c index 6a8dadea40f92..79074d22959b9 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c @@ -2897,8 +2897,6 @@ static void gfx_v6_0_get_csb_buffer(struct amdgpu_device *adev, buffer[count++] = cpu_to_le32(ext->reg_index - 0xa000); for (i = 0; i < ext->reg_count; i++) buffer[count++] = cpu_to_le32(ext->extent[i]); - } else { - return; } } } -- 2.39.5

3 weeks, 2 days

1
42
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2025