FAILED: patch "[PATCH] mm: zswap: fix missing folio cleanup in writeback race path" failed to apply to 6.6-stable tree

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 <[email protected]>.

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 e3b63e966cac0bf78aaa1efede1827a252815a1d
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2024022611-tropics-deferred-2483@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^..

Possible dependencies:

e3b63e966cac ("mm: zswap: fix missing folio cleanup in writeback race path") 96c7b0b42239 ("mm: return the folio from __read_swap_cache_async()") e947ba0bbf47 ("mm/zswap: cleanup zswap_writeback_entry()") 32acba4c0483 ("mm/zswap: refactor out __zswap_load()") c75f5c1e0f1d ("mm/zswap: reuse dstmem when decompress") b5ba474f3f51 ("zswap: shrink zswap pool based on memory pressure") a65b0e7607cc ("zswap: make shrinking memcg-aware")
ddc1a5cbc05d ("mempolicy: alloc_pages_mpol() for NUMA policy without vma") 23e4883248f0 ("mm: add page_rmappable_folio() wrapper") c36f6e6dff4d ("mempolicy trivia: slightly more consistent naming") 7f1ee4e20708 ("mempolicy trivia: delete those ancient pr_debug()s") 1cb5d11a370f ("mempolicy: fix migrate_pages(2) syscall return nr_failed") 3657fdc2451a ("mm: move vma_policy() and anon_vma_name() decls to mm_types.h") 3022fd7af960 ("shmem: _add_to_page_cache() before shmem_inode_acct_blocks()") 054a9f7ccd0a ("shmem: move memcg charge out of shmem_add_to_page_cache()") 4199f51a7eb2 ("shmem: shmem_acct_blocks() and shmem_inode_acct_blocks()") e3e1a5067fd2 ("shmem: remove vma arg from shmem_get_folio_gfp()") 75c70128a673 ("mm: mempolicy: make mpol_misplaced() to take a folio") cda6d93672ac ("mm: memory: make numa_migrate_prep() to take a folio") 6695cf68b15c ("mm: memory: use a folio in do_numa_page()")

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From e3b63e966cac0bf78aaa1efede1827a252815a1d Mon Sep 17 00:00:00 2001
From: Yosry Ahmed <[email protected]>
Date: Thu, 25 Jan 2024 08:51:27 +0000
Subject: [PATCH] mm: zswap: fix missing folio cleanup in writeback race path

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.

index 350dd2fc8159..d2423247acfd 100644
@@ -1440,6 +1440,8 @@ static int zswap_writeback_entry(struct zswap_entry *entry,
 	if (zswap_rb_search(&tree->rbroot, swp_offset(entry->swpentry)) != entry) {
 		spin_unlock(&tree->lock);
 		delete_from_swap_cache(folio);
+		folio_unlock(folio);
+		folio_put(folio);
 		return -ENOMEM;
 	}
 	spin_unlock(&tree->lock);

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.

---
 mm/zswap.c | 2 ++
 1 file changed, 2 insertions(+)

index 37d2b1cb2ecb4..4e0f0a7b30737 100644
@@ -1100,6 +1100,8 @@ static int zswap_writeback_entry(struct zswap_entry *entry,
 	if (zswap_rb_search(&tree->rbroot, swp_offset(entry->swpentry)) != entry) {
 		spin_unlock(&tree->lock);
 		delete_from_swap_cache(page_folio(page));
+		unlock_page(page);
+		put_page(page);
 		ret = -ENOMEM;
 		goto fail;
 	}

2.44.0.rc1.240.g4c46232300-goog

What tree is this for?

thanks,

greg k-h

This is for 6.6.y, sorry I messed up the subject prefix. Do I need to resend?

Ah, here is the 6.6.y version, missed it, sorry for the noise. I'll go queue this and the 6.1.y version up now.

thanks,

greg k-h