kernel/linux.git, branch v6.6.20

Linux 6.6.20

2024-03-02T17:23:09+00:00

Signed-off-by: Greg Kroah-Hartman

fs/ntfs3: fix build without CONFIG_NTFS3_LZX_XPRESS

2024-03-02T17:23:09+00:00

commit c8e314624a1666ed2eec28549713021a8ec801e9 upstream. When CONFIG_NTFS3_LZX_XPRESS is not set then we get the following build error: fs/ntfs3/frecord.c:2460:16: error: unused variable ‘i_size’ Signed-off-by: Mark O'Donovan Fixes: 4fd6c08a16d7 ("fs/ntfs3: Use i_size_read and i_size_write") Tested-by: Chris Clayton Signed-off-by: Linus Torvalds Reported-by: Rainer Fiebig Cc: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman

Linux 6.6.19

2024-03-01T12:35:11+00:00

Link: https://lore.kernel.org/r/20240227131625.847743063@linuxfoundation.org Tested-by: Luna Jernberg Tested-by: SeongJae Park Tested-by: Allen Pais Tested-by: Florian Fainelli Tested-by: Kelsey Steele Tested-by: Takeshi Ogasawara Tested-by: Jon Hunter Tested-by: Conor Dooley Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Harshit Mogalapalli Tested-by: Ron Economos Tested-by: kernelci.org bot Signed-off-by: Greg Kroah-Hartman

ahci: Extend ASM1061 43-bit DMA address quirk to other ASM106x parts

2024-03-01T12:35:11+00:00

commit 51af8f255bdaca6d501afc0d085b808f67b44d91 upstream. ASMedia have confirmed that all ASM106x parts currently listed in ahci_pci_tbl[] suffer from the 43-bit DMA address limitation that we ran into on the ASM1061, and therefore, we need to apply the quirk added by commit 20730e9b2778 ("ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers") to the other supported ASM106x parts as well. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-ide/ZbopwKZJAKQRA4Xv@x1-carbon/ Signed-off-by: Lennert Buytenhek [cassel: add link to ASMedia confirmation email] Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman

ata: ahci: add identifiers for ASM2116 series adapters

2024-03-01T12:35:11+00:00

commit 3bf6141060948e27b62b13beb216887f2e54591e upstream. Add support for PCIe SATA adapter cards based on Asmedia 2116 controllers. These cards can provide up to 10 SATA ports on PCIe card. Signed-off-by: Szuying Chen Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman

mptcp: add needs_id for netlink appending addr

2024-03-01T12:35:11+00:00

commit 584f3894262634596532cf43a5e782e34a0ce374 upstream. Just the same as userspace PM, a new parameter needs_id is added for in-kernel PM mptcp_pm_nl_append_new_local_addr() too. Add a new helper mptcp_pm_has_addr_attr_id() to check whether an address ID is set from PM or not. In mptcp_pm_nl_get_local_id(), needs_id is always true, but in mptcp_pm_nl_add_addr_doit(), pass mptcp_pm_has_addr_attr_id() to needs_it. Fixes: efd5a4c04e18 ("mptcp: add the address ID assignment bitmap") Cc: stable@vger.kernel.org Signed-off-by: Geliang Tang Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: David S. Miller Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman

mptcp: userspace pm send RM_ADDR for ID 0

2024-03-01T12:35:11+00:00

commit 84c531f54ad9a124a924c9505d74e33d16965146 upstream. This patch adds the ability to send RM_ADDR for local ID 0. Check whether id 0 address is removed, if not, put id 0 into a removing list, pass it to mptcp_pm_remove_addr() to remove id 0 address. There is no reason not to allow the userspace to remove the initial address (ID 0). This special case was not taken into account not letting the userspace to delete all addresses as announced. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/379 Reviewed-by: Matthieu Baerts Signed-off-by: Geliang Tang Signed-off-by: Mat Martineau Link: https://lore.kernel.org/r/20231025-send-net-next-20231025-v1-3-db8f25f798eb@kernel.org Signed-off-by: Jakub Kicinski Fixes: d9a4594edabf ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE") Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman

selftests: mptcp: add mptcp_lib_get_counter

2024-03-01T12:35:11+00:00

commit 61c131f5d4d2b79904af2fdcb2839a9db8e7c55c upstream. To avoid duplicated code in different MPTCP selftests, we can add and use helpers defined in mptcp_lib.sh. The helper get_counter() in mptcp_join.sh and get_mib_counter() in mptcp_connect.sh have the same functionality, export get_counter() into mptcp_lib.sh and rename it as mptcp_lib_get_counter(). Use this new helper instead of get_counter() and get_mib_counter(). Use this helper in test_prio() in userspace_pm.sh too instead of open-coding. Reviewed-by: Matthieu Baerts Signed-off-by: Geliang Tang Signed-off-by: Mat Martineau Link: https://lore.kernel.org/r/20231128-send-net-next-2023107-v4-11-8d6b94150f6b@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman

selftests: mptcp: join: stop transfer when check is done (part 2)

2024-03-01T12:35:10+00:00

commit 04b57c9e096a9479fe0ad31e3956e336fa589cb2 upstream. Since the "Fixes" commits mentioned below, the newly added "userspace pm" subtests of mptcp_join selftests are launching the whole transfer in the background, do the required checks, then wait for the end of transfer. There is no need to wait longer, especially because the checks at the end of the transfer are ignored (which is fine). This saves quite a few seconds on slow environments. While at it, use 'mptcp_lib_kill_wait()' helper everywhere, instead of on a specific one with 'kill_tests_wait()'. Fixes: b2e2248f365a ("selftests: mptcp: userspace pm create id 0 subflow") Fixes: e3b47e460b4b ("selftests: mptcp: userspace pm remove initial subflow") Fixes: b9fb176081fb ("selftests: mptcp: userspace pm send RM_ADDR for ID 0") Cc: stable@vger.kernel.org Reviewed-and-tested-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://lore.kernel.org/r/20240131-upstream-net-20240131-mptcp-ci-issues-v1-9-4c1c11e571ff@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman

mm: zswap: fix missing folio cleanup in writeback race path

2024-03-01T12:35:10+00:00

commit e3b63e966cac0bf78aaa1efede1827a252815a1d upstream. In zswap_writeback_entry(), after we get a folio from __read_swap_cache_async(), we grab the tree lock again to check that the swap entry was not invalidated and recycled. If it was, we delete the folio we just added to the swap cache and exit. However, __read_swap_cache_async() returns the folio locked when it is newly allocated, which is always true for this path, and the folio is ref'd. Make sure to unlock and put the folio before returning. This was discovered by code inspection, probably because this path handles a race condition that should not happen often, and the bug would not crash the system, it will only strand the folio indefinitely. Link: https://lkml.kernel.org/r/20240125085127.1327013-1-yosryahmed@google.com Fixes: 04fc7816089c ("mm: fix zswap writeback race condition") Signed-off-by: Yosry Ahmed Reviewed-by: Chengming Zhou Acked-by: Johannes Weiner Reviewed-by: Nhat Pham Cc: Domenico Cerasuolo Cc: Signed-off-by: Andrew Morton Signed-off-by: Yosry Ahmed Signed-off-by: Greg Kroah-Hartman