AI Trajectory

null

{
  "EnableConfigs": [
    "ZSWAP",
    "ZSWAP_DEFAULT_ON"
  ],
  "FocusSymbols": [
    "zswap_store",
    "zswap_load",
    "zswap_invalidate",
    "zswap_swapon",
    "zswap_swapoff"
  ],
  "Reasoning": "The patch modifies the core zswap logic by replacing the pool pointer in zswap_entry with a u16 index mapped via an xarray. This affects pool creation, destruction, entry allocation, and freeing. Fuzzing should focus on the main zswap entry points to ensure the new index-based pool lookup and lifetime management are correct.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 4c43f5378bb6d7be3c426e4218a92209f976805a\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Mon Jul 27 05:33:03 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/mm/zswap.c b/mm/zswap.c\nindex 4e76a4a87cdcc0..6c29098da8d5ea 100644\n--- a/mm/zswap.c\n+++ b/mm/zswap.c\n@@ -35,6 +35,7 @@\n #include \u003clinux/pagemap.h\u003e\n #include \u003clinux/workqueue.h\u003e\n #include \u003clinux/list_lru.h\u003e\n+#include \u003clinux/xarray.h\u003e\n #include \u003clinux/zsmalloc.h\u003e\n \n #include \"swap.h\"\n@@ -157,9 +158,22 @@ struct zswap_pool {\n \tstruct list_head list;\n \tstruct work_struct release_work;\n \tstruct hlist_node node;\n+\tu16 idx;\n \tchar tfm_name[CRYPTO_MAX_ALG_NAME];\n };\n \n+/*\n+ * Entries store a u16 pool index instead of an 8-byte pool pointer.\n+ * Indices are allocated here at pool creation and released at destruction.\n+ * Live entries pin the pool, so its index is not reused under them.\n+ */\n+static DEFINE_XARRAY_ALLOC(zswap_pools_xa);\n+\n+static struct zswap_pool *zswap_pool_by_index(u16 idx)\n+{\n+\treturn xa_load(\u0026zswap_pools_xa, idx);\n+}\n+\n /* Global LRU lists shared by all zswap pools. */\n static struct list_lru zswap_list_lru;\n \n@@ -182,7 +196,7 @@ static struct shrinker *zswap_shrinker;\n  *              writeback logic. The entry is only reclaimed by the writeback\n  *              logic if referenced is unset. See comments in the shrinker\n  *              section for context.\n- * pool - the zswap_pool the entry's data is in\n+ * pool_idx - zswap_pool index, resolved via zswap_pool_by_index().\n  * handle - zsmalloc allocation handle that stores the compressed page data\n  * objcg - the obj_cgroup that the compressed memory is charged to\n  * lru - handle to the pool's lru used to evict pages.\n@@ -191,12 +205,20 @@ struct zswap_entry {\n \tswp_entry_t swpentry;\n \tunsigned int length;\n \tbool referenced;\n-\tstruct zswap_pool *pool;\n+\tu16 pool_idx;\n \tunsigned long handle;\n \tstruct obj_cgroup *objcg;\n \tstruct list_head lru;\n };\n \n+static struct zswap_pool *zswap_entry_pool(struct zswap_entry *entry)\n+{\n+\tstruct zswap_pool *pool = zswap_pool_by_index(entry-\u003epool_idx);\n+\n+\tVM_WARN_ON_ONCE(!pool);\n+\treturn pool;\n+}\n+\n static struct xarray *zswap_trees[MAX_SWAPFILES];\n static unsigned int nr_zswap_trees[MAX_SWAPFILES];\n \n@@ -275,6 +297,7 @@ static struct zswap_pool *zswap_pool_create(char *compressor)\n \tstruct zswap_pool *pool;\n \tchar name[38]; /* 'zswap' + 32 char (max) num + \\0 */\n \tint ret, cpu;\n+\tu32 idx;\n \n \tif (!zswap_has_pool \u0026\u0026 !strcmp(compressor, ZSWAP_PARAM_UNSET))\n \t\treturn NULL;\n@@ -322,10 +345,18 @@ static struct zswap_pool *zswap_pool_create(char *compressor)\n \t\tgoto ref_fail;\n \tINIT_LIST_HEAD(\u0026pool-\u003elist);\n \n+\tret = xa_alloc(\u0026zswap_pools_xa, \u0026idx, pool, xa_limit_16b,\n+\t\t       GFP_KERNEL);\n+\tif (ret)\n+\t\tgoto idx_fail;\n+\tpool-\u003eidx = idx;\n+\n \tzswap_pool_debug(\"created\", pool);\n \n \treturn pool;\n \n+idx_fail:\n+\tpercpu_ref_exit(\u0026pool-\u003eref);\n ref_fail:\n \tcpuhp_state_remove_instance(CPUHP_MM_ZSWP_POOL_PREPARE, \u0026pool-\u003enode);\n \n@@ -366,6 +397,8 @@ static void zswap_pool_destroy(struct zswap_pool *pool)\n \n \tzswap_pool_debug(\"destroying\", pool);\n \n+\txa_erase(\u0026zswap_pools_xa, pool-\u003eidx);\n+\n \tcpuhp_state_remove_instance(CPUHP_MM_ZSWP_POOL_PREPARE, \u0026pool-\u003enode);\n \n \tfor_each_possible_cpu(cpu)\n@@ -764,9 +797,11 @@ static void zswap_entry_cache_free(struct zswap_entry *entry)\n  */\n static void zswap_entry_free(struct zswap_entry *entry)\n {\n+\tstruct zswap_pool *pool = zswap_entry_pool(entry);\n+\n \tzswap_lru_del(\u0026zswap_list_lru, entry);\n-\tzs_free(entry-\u003epool-\u003ezs_pool, entry-\u003ehandle);\n-\tzswap_pool_put(entry-\u003epool);\n+\tzs_free(pool-\u003ezs_pool, entry-\u003ehandle);\n+\tzswap_pool_put(pool);\n \tif (entry-\u003eobjcg) {\n \t\tobj_cgroup_uncharge_zswap(entry-\u003eobjcg, entry-\u003elength);\n \t\tobj_cgroup_put(entry-\u003eobjcg);\n@@ -923,7 +958,7 @@ static bool zswap_compress(struct page *page, struct zswap_entry *entry,\n \n static bool zswap_decompress(struct zswap_entry *entry, struct folio *folio)\n {\n-\tstruct zswap_pool *pool = entry-\u003epool;\n+\tstruct zswap_pool *pool = zswap_entry_pool(entry);\n \tstruct scatterlist input[2]; /* zsmalloc returns an SG list 1-2 entries */\n \tstruct scatterlist output;\n \tstruct crypto_acomp_ctx *acomp_ctx;\n@@ -964,7 +999,7 @@ static bool zswap_decompress(struct zswap_entry *entry, struct folio *folio)\n \tpr_alert_ratelimited(\"Decompression error from zswap (%d:%lu %s %u-\u003e%d)\\n\",\n \t\t\t\t\t\tswp_type(entry-\u003eswpentry),\n \t\t\t\t\t\tswp_offset(entry-\u003eswpentry),\n-\t\t\t\t\t\tentry-\u003epool-\u003etfm_name,\n+\t\t\t\t\t\tpool-\u003etfm_name,\n \t\t\t\t\t\tentry-\u003elength, dlen);\n \treturn false;\n }\n@@ -1457,7 +1492,7 @@ static bool zswap_store_page(struct page *page,\n \t *    The publishing order matters to prevent writeback from seeing\n \t *    an incoherent entry.\n \t */\n-\tentry-\u003epool = pool;\n+\tentry-\u003epool_idx = pool-\u003eidx;\n \tentry-\u003eswpentry = page_swpentry;\n \tentry-\u003eobjcg = objcg;\n \tentry-\u003ereferenced = true;\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "ZSWAP",
    "ZSWAP_DEFAULT_ON"
  ],
  "FocusSymbols": [
    "zswap_store",
    "zswap_load",
    "zswap_invalidate",
    "zswap_swapon",
    "zswap_swapoff"
  ],
  "Reasoning": "The patch modifies the core zswap logic by replacing the pool pointer in zswap_entry with a u16 index mapped via an xarray. This affects pool creation, destruction, entry allocation, and freeing. Fuzzing should focus on the main zswap entry points to ensure the new index-based pool lookup and lifetime management are correct.",
  "WorthFuzzing": true
}

You are an expert Linux kernel maintainer.
Your job is to review a provided patch series and determine
if it makes functional changes to the kernel that should be fuzzed.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively
use your code access tools to examine the actual source code and confirm any assumptions.

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
  even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).
- Code in vendor-specific PCIe switch, SmartNIC, or GPU drivers (e.g., mlxsw, pds_core, qed,
  ionic, amdgpu) that require physical PCIe hardware cards not emulated in standard QEMU.
- Driver .remove, .shutdown, or pci_unregister_driver teardown callbacks (e.g., igb_remove)
  that are executed only during PCI hot-unplug or sysfs driver unbind operations.

If it modifies reachable core kernel logic, drivers, or architectures, use your code search
tools to verify the code can be executed, then return WorthFuzzing=true.

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
   Prefer non-static, non-inlined API entrypoint functions over internal static helper functions
   (which are inlined by the compiler and do not have distinct symbol addresses).
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Also check "depends on" lines in Kconfig to include any non-standard parent subsystem configs
   needed for Kbuild to compile the code statically into vmlinux. List them in the EnableConfigs
   output array, and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

For your convenience, here is the diff of the changes:
commit 4c43f5378bb6d7be3c426e4218a92209f976805a
Author: syz-cluster <triage@syzkaller.com>
Date:   Mon Jul 27 05:33:03 2026 +0000

    syz-cluster: applied patch under review

diff --git a/mm/zswap.c b/mm/zswap.c
index 4e76a4a87cdcc0..6c29098da8d5ea 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -35,6 +35,7 @@
 #include <linux/pagemap.h>
 #include <linux/workqueue.h>
 #include <linux/list_lru.h>
+#include <linux/xarray.h>
 #include <linux/zsmalloc.h>
 
 #include "swap.h"
@@ -157,9 +158,22 @@ struct zswap_pool {
 	struct list_head list;
 	struct work_struct release_work;
 	struct hlist_node node;
+	u16 idx;
 	char tfm_name[CRYPTO_MAX_ALG_NAME];
 };
 
+/*
+ * Entries store a u16 pool index instead of an 8-byte pool pointer.
+ * Indices are allocated here at pool creation and released at destruction.
+ * Live entries pin the pool, so its index is not reused under them.
+ */
+static DEFINE_XARRAY_ALLOC(zswap_pools_xa);
+
+static struct zswap_pool *zswap_pool_by_index(u16 idx)
+{
+	return xa_load(&zswap_pools_xa, idx);
+}
+
 /* Global LRU lists shared by all zswap pools. */
 static struct list_lru zswap_list_lru;
 
@@ -182,7 +196,7 @@ static struct shrinker *zswap_shrinker;
  *              writeback logic. The entry is only reclaimed by the writeback
  *              logic if referenced is unset. See comments in the shrinker
  *              section for context.
- * pool - the zswap_pool the entry's data is in
+ * pool_idx - zswap_pool index, resolved via zswap_pool_by_index().
  * handle - zsmalloc allocation handle that stores the compressed page data
  * objcg - the obj_cgroup that the compressed memory is charged to
  * lru - handle to the pool's lru used to evict pages.
@@ -191,12 +205,20 @@ struct zswap_entry {
 	swp_entry_t swpentry;
 	unsigned int length;
 	bool referenced;
-	struct zswap_pool *pool;
+	u16 pool_idx;
 	unsigned long handle;
 	struct obj_cgroup *objcg;
 	struct list_head lru;
 };
 
+static struct zswap_pool *zswap_entry_pool(struct zswap_entry *entry)
+{
+	struct zswap_pool *pool = zswap_pool_by_index(entry->pool_idx);
+
+	VM_WARN_ON_ONCE(!pool);
+	return pool;
+}
+
 static struct xarray *zswap_trees[MAX_SWAPFILES];
 static unsigned int nr_zswap_trees[MAX_SWAPFILES];
 
@@ -275,6 +297,7 @@ static struct zswap_pool *zswap_pool_create(char *compressor)
 	struct zswap_pool *pool;
 	char name[38]; /* 'zswap' + 32 char (max) num + \0 */
 	int ret, cpu;
+	u32 idx;
 
 	if (!zswap_has_pool && !strcmp(compressor, ZSWAP_PARAM_UNSET))
 		return NULL;
@@ -322,10 +345,18 @@ static struct zswap_pool *zswap_pool_create(char *compressor)
 		goto ref_fail;
 	INIT_LIST_HEAD(&pool->list);
 
+	ret = xa_alloc(&zswap_pools_xa, &idx, pool, xa_limit_16b,
+		       GFP_KERNEL);
+	if (ret)
+		goto idx_fail;
+	pool->idx = idx;
+
 	zswap_pool_debug("created", pool);
 
 	return pool;
 
+idx_fail:
+	percpu_ref_exit(&pool->ref);
 ref_fail:
 	cpuhp_state_remove_instance(CPUHP_MM_ZSWP_POOL_PREPARE, &pool->node);
 
@@ -366,6 +397,8 @@ static void zswap_pool_destroy(struct zswap_pool *pool)
 
 	zswap_pool_debug("destroying", pool);
 
+	xa_erase(&zswap_pools_xa, pool->idx);
+
 	cpuhp_state_remove_instance(CPUHP_MM_ZSWP_POOL_PREPARE, &pool->node);
 
 	for_each_possible_cpu(cpu)
@@ -764,9 +797,11 @@ static void zswap_entry_cache_free(struct zswap_entry *entry)
  */
 static void zswap_entry_free(struct zswap_entry *entry)
 {
+	struct zswap_pool *pool = zswap_entry_pool(entry);
+
 	zswap_lru_del(&zswap_list_lru, entry);
-	zs_free(entry->pool->zs_pool, entry->handle);
-	zswap_pool_put(entry->pool);
+	zs_free(pool->zs_pool, entry->handle);
+	zswap_pool_put(pool);
 	if (entry->objcg) {
 		obj_cgroup_uncharge_zswap(entry->objcg, entry->length);
 		obj_cgroup_put(entry->objcg);
@@ -923,7 +958,7 @@ static bool zswap_compress(struct page *page, struct zswap_entry *entry,
 
 static bool zswap_decompress(struct zswap_entry *entry, struct folio *folio)
 {
-	struct zswap_pool *pool = entry->pool;
+	struct zswap_pool *pool = zswap_entry_pool(entry);
 	struct scatterlist input[2]; /* zsmalloc returns an SG list 1-2 entries */
 	struct scatterlist output;
 	struct crypto_acomp_ctx *acomp_ctx;
@@ -964,7 +999,7 @@ static bool zswap_decompress(struct zswap_entry *entry, struct folio *folio)
 	pr_alert_ratelimited("Decompression error from zswap (%d:%lu %s %u->%d)\n",
 						swp_type(entry->swpentry),
 						swp_offset(entry->swpentry),
-						entry->pool->tfm_name,
+						pool->tfm_name,
 						entry->length, dlen);
 	return false;
 }
@@ -1457,7 +1492,7 @@ static bool zswap_store_page(struct page *page,
 	 *    The publishing order matters to prevent writeback from seeing
 	 *    an incoherent entry.
 	 */
-	entry->pool = pool;
+	entry->pool_idx = pool->idx;
 	entry->swpentry = page_swpentry;
 	entry->objcg = objcg;
 	entry->referenced = true;

gemini-3.1-pro-preview

null

null

							input: 3672
							output: 18
							thoughts: 144
						

**Analyzing a Zswap Optimization Patch**

Okay, so I'm looking at this patch for `mm/zswap.c`. It's a pretty interesting optimization. Essentially, they're swapping out a full 8-byte pointer, the `struct zswap_pool *pool` within the `struct zswap_entry`, and replacing it with a `u16 pool_idx`. That's a significant size reduction, which is always a good thing, especially in the kernel, where every byte counts. The implementation uses an xarray, `zswap_pools_xa`, to handle the mapping between these `pool_idx` values and the actual `struct zswap_pool` pointers. This is a functional change, a core part of zswap, not just some trivial adjustment.

Now, before I dig deeper into the code itself, I need to understand the context. Is Zswap enabled by default in the kernel config, or is it something that requires a specific option to be turned on? I'll run `grepper` to search through the Kconfig files for `ZSWAP`. That should quickly give me the necessary information to evaluate the impact and scope of this patch.

{
  "Expression": "config ZSWAP"
}

{
  "Output": "mm/Kconfig=12=menuconfig SWAP\n--\nmm/Kconfig-21-\nmm/Kconfig:22:config ZSWAP\nmm/Kconfig-23-\tbool \"Compressed cache for swap pages\"\n--\nmm/Kconfig-34-\nmm/Kconfig:35:config ZSWAP_DEFAULT_ON\nmm/Kconfig-36-\tbool \"Enable the compressed cache for swap pages by default\"\n--\nmm/Kconfig-44-\nmm/Kconfig:45:config ZSWAP_SHRINKER_DEFAULT_ON\nmm/Kconfig-46-\tbool \"Shrink the zswap pool on memory pressure\"\n--\nmm/Kconfig=59=choice\n--\nmm/Kconfig-76-\nmm/Kconfig:77:config ZSWAP_COMPRESSOR_DEFAULT_DEFLATE\nmm/Kconfig-78-\tbool \"Deflate\"\n--\nmm/Kconfig-82-\nmm/Kconfig:83:config ZSWAP_COMPRESSOR_DEFAULT_LZO\nmm/Kconfig-84-\tbool \"LZO\"\n--\nmm/Kconfig-88-\nmm/Kconfig:89:config ZSWAP_COMPRESSOR_DEFAULT_842\nmm/Kconfig-90-\tbool \"842\"\n--\nmm/Kconfig-94-\nmm/Kconfig:95:config ZSWAP_COMPRESSOR_DEFAULT_LZ4\nmm/Kconfig-96-\tbool \"LZ4\"\n--\nmm/Kconfig-100-\nmm/Kconfig:101:config ZSWAP_COMPRESSOR_DEFAULT_LZ4HC\nmm/Kconfig-102-\tbool \"LZ4HC\"\n--\nmm/Kconfig-106-\nmm/Kconfig:107:config ZSWAP_COMPRESSOR_DEFAULT_ZSTD\nmm/Kconfig-108-\tbool \"zstd\"\n--\nmm/Kconfig=112=endchoice\nmm/Kconfig-113-\nmm/Kconfig:114:config ZSWAP_COMPRESSOR_DEFAULT\nmm/Kconfig-115-       string\n"
}

gemini-3.1-pro-preview

null

null

							input: 4623
							output: 28
							thoughts: 68
						

Okay, here's my take on those preliminary thoughts, focusing on the configuration aspect, assuming I'm building a kernel:

**Kernel Configuration Considerations for Zswap Testing**

Alright, I'm thinking about how best to ensure that zswap is thoroughly tested. The critical thing here is to make sure we've got the relevant options enabled, specifically `CONFIG_ZSWAP`. Makes sense, of course – without that, there's no zswap to test. And, to simplify the process and guarantee it's actually running, I'm leaning towards also enabling `CONFIG_ZSWAP_DEFAULT_ON`. That seems like the most straightforward way to have zswap active by default during initial testing and to confirm the expected behavior.

Of course, we'll need regular swap support, which is `CONFIG_SWAP`. It's almost always enabled, but I should probably confirm that explicitly. It'd be foolish to overlook that.

So, to make sure I don't miss anything, my next step is to dive into the `mm/Kconfig` file. I need to understand all the dependencies surrounding `ZSWAP`. Are there any other config options that are required, or that impact its behavior, that I'm overlooking? Time to get granular with the kernel configuration settings.

{
  "Expression": "config ZSWAP",
  "PathPrefix": "mm/Kconfig"
}

{
  "Output": "mm/Kconfig=12=menuconfig SWAP\n--\nmm/Kconfig-21-\nmm/Kconfig:22:config ZSWAP\nmm/Kconfig-23-\tbool \"Compressed cache for swap pages\"\n--\nmm/Kconfig-34-\nmm/Kconfig:35:config ZSWAP_DEFAULT_ON\nmm/Kconfig-36-\tbool \"Enable the compressed cache for swap pages by default\"\n--\nmm/Kconfig-44-\nmm/Kconfig:45:config ZSWAP_SHRINKER_DEFAULT_ON\nmm/Kconfig-46-\tbool \"Shrink the zswap pool on memory pressure\"\n--\nmm/Kconfig=59=choice\n--\nmm/Kconfig-76-\nmm/Kconfig:77:config ZSWAP_COMPRESSOR_DEFAULT_DEFLATE\nmm/Kconfig-78-\tbool \"Deflate\"\n--\nmm/Kconfig-82-\nmm/Kconfig:83:config ZSWAP_COMPRESSOR_DEFAULT_LZO\nmm/Kconfig-84-\tbool \"LZO\"\n--\nmm/Kconfig-88-\nmm/Kconfig:89:config ZSWAP_COMPRESSOR_DEFAULT_842\nmm/Kconfig-90-\tbool \"842\"\n--\nmm/Kconfig-94-\nmm/Kconfig:95:config ZSWAP_COMPRESSOR_DEFAULT_LZ4\nmm/Kconfig-96-\tbool \"LZ4\"\n--\nmm/Kconfig-100-\nmm/Kconfig:101:config ZSWAP_COMPRESSOR_DEFAULT_LZ4HC\nmm/Kconfig-102-\tbool \"LZ4HC\"\n--\nmm/Kconfig-106-\nmm/Kconfig:107:config ZSWAP_COMPRESSOR_DEFAULT_ZSTD\nmm/Kconfig-108-\tbool \"zstd\"\n--\nmm/Kconfig=112=endchoice\nmm/Kconfig-113-\nmm/Kconfig:114:config ZSWAP_COMPRESSOR_DEFAULT\nmm/Kconfig-115-       string\n"
}

gemini-3.1-pro-preview

null

null

							input: 5531
							output: 31
							thoughts: 16
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Diving into the Kernel Configuration Landscape**

Okay, so I need to understand something related to this configuration, and my gut feeling says the core is in the `mm/Kconfig` file. Specifically, I'm thinking the relevant section is probably around line 22 – that's often a good starting point for memory management options. It's a broad area, so zeroing in like this helps. Let's see what gems we find. Hopefully, it is not too deep.

{
  "File": "mm/Kconfig",
  "FirstLine": 15,
  "LineCount": 30
}

{
  "Contents": "  15:\t\tdefault y\n  16:\t\thelp\n  17:\t\t  This option allows you to choose whether you want to have support\n  18:\t\t  for so called swap devices or swap files in your kernel that are\n  19:\t\t  used to provide more virtual memory than the actual RAM present\n  20:\t\t  in your computer.  If unsure say Y.\n  21:\t\n  22:\tconfig ZSWAP\n  23:\t\tbool \"Compressed cache for swap pages\"\n  24:\t\tdepends on SWAP\n  25:\t\tselect CRYPTO\n  26:\t\tselect ZSMALLOC\n  27:\t\thelp\n  28:\t\t  A lightweight compressed cache for swap pages.  It takes\n  29:\t\t  pages that are in the process of being swapped out and attempts to\n  30:\t\t  compress them into a dynamically allocated RAM-based memory pool.\n  31:\t\t  This can result in a significant I/O reduction on swap device and,\n  32:\t\t  in the case where decompressing from RAM is faster than swap device\n  33:\t\t  reads, can also improve workload performance.\n  34:\t\n  35:\tconfig ZSWAP_DEFAULT_ON\n  36:\t\tbool \"Enable the compressed cache for swap pages by default\"\n  37:\t\tdepends on ZSWAP\n  38:\t\thelp\n  39:\t\t  If selected, the compressed cache for swap pages will be enabled\n  40:\t\t  at boot, otherwise it will be disabled.\n  41:\t\n  42:\t\t  The selection made here can be overridden by using the kernel\n  43:\t\t  command line 'zswap.enabled=' option.\n  44:\t\n"
}

gemini-3.1-pro-preview

null

null

							input: 6121
							output: 44
							thoughts: 105
						

**Zswap Focus for Fuzzing**

Okay, so I see `ZSWAP` and `ZSWAP_DEFAULT_ON` are in play, good. Now, let's get down to brass tacks: which functions are the real targets for fuzzing here? The patch points to modifications in `zswap_pool_create`, `zswap_pool_destroy`, `zswap_entry_free`, `zswap_decompress`, and `zswap_store_page`.

Right, time to dig into `mm/zswap.c`. We need to determine which of these functions are actually exposed as API entry points or, at the very least, aren't declared as `static`. That's where the interesting stuff for fuzzing will lie. Let's see what we find.

{
  "Expression": "^(static )?[a-z_]+ zswap_[a-z_]+\\(",
  "PathPrefix": "mm/zswap.c"
}

{
  "Output": "mm/zswap.c=79=static bool zswap_pool_reached_full;\n--\nmm/zswap.c-86-\nmm/zswap.c:87:static int zswap_setup(void);\nmm/zswap.c-88-\n--\nmm/zswap.c=91=static bool zswap_enabled = IS_ENABLED(CONFIG_ZSWAP_DEFAULT_ON);\nmm/zswap.c:92:static int zswap_enabled_param_set(const char *,\nmm/zswap.c-93-\t\t\t\t   const struct kernel_param *);\n--\nmm/zswap.c=101=static char *zswap_compressor = CONFIG_ZSWAP_COMPRESSOR_DEFAULT;\nmm/zswap.c:102:static int zswap_compressor_param_set(const char *,\nmm/zswap.c-103-\t\t\t\t      const struct kernel_param *);\n--\nmm/zswap.c=124=module_param_named(shrinker_enabled, zswap_shrinker_enabled, bool, 0644);\nmm/zswap.c-125-\nmm/zswap.c:126:bool zswap_is_enabled(void)\nmm/zswap.c-127-{\n--\nmm/zswap.c-130-\nmm/zswap.c:131:bool zswap_never_enabled(void)\nmm/zswap.c-132-{\n--\nmm/zswap.c=375=static struct zswap_pool *__zswap_pool_create_fallback(void)\n--\nmm/zswap.c-393-\nmm/zswap.c:394:static void zswap_pool_destroy(struct zswap_pool *pool)\nmm/zswap.c-395-{\n--\nmm/zswap.c=448=static int __must_check zswap_pool_tryget(struct zswap_pool *pool)\n--\nmm/zswap.c-456-/* The caller must already have a reference. */\nmm/zswap.c:457:static void zswap_pool_get(struct zswap_pool *pool)\nmm/zswap.c-458-{\n--\nmm/zswap.c-461-\nmm/zswap.c:462:static void zswap_pool_put(struct zswap_pool *pool)\nmm/zswap.c-463-{\n--\nmm/zswap.c=529=unsigned long zswap_total_pages(void)\n--\nmm/zswap.c-541-\nmm/zswap.c:542:static bool zswap_check_limits(void)\nmm/zswap.c-543-{\n--\nmm/zswap.c-560-\nmm/zswap.c:561:static int zswap_compressor_param_set(const char *val, const struct kernel_param *kp)\nmm/zswap.c-562-{\n--\nmm/zswap.c-649-\nmm/zswap.c:650:static int zswap_enabled_param_set(const char *val,\nmm/zswap.c-651-\t\t\t\t   const struct kernel_param *kp)\n--\nmm/zswap.c=696=static inline int entry_to_nid(struct zswap_entry *entry)\n--\nmm/zswap.c-700-\nmm/zswap.c:701:static void zswap_lru_add(struct list_lru *list_lru, struct zswap_entry *entry)\nmm/zswap.c-702-{\n--\nmm/zswap.c-723-\nmm/zswap.c:724:static void zswap_lru_del(struct list_lru *list_lru, struct zswap_entry *entry)\nmm/zswap.c-725-{\n--\nmm/zswap.c-735-\nmm/zswap.c:736:void zswap_lruvec_state_init(struct lruvec *lruvec)\nmm/zswap.c-737-{\n--\nmm/zswap.c-740-\nmm/zswap.c:741:void zswap_folio_swapin(struct folio *folio)\nmm/zswap.c-742-{\n--\nmm/zswap.c-762- */\nmm/zswap.c:763:void zswap_memcg_offline_cleanup(struct mem_cgroup *memcg)\nmm/zswap.c-764-{\n--\nmm/zswap.c=780=static struct zswap_entry *zswap_entry_cache_alloc(gfp_t gfp, int nid)\n--\nmm/zswap.c-788-\nmm/zswap.c:789:static void zswap_entry_cache_free(struct zswap_entry *entry)\nmm/zswap.c-790-{\n--\nmm/zswap.c-797- */\nmm/zswap.c:798:static void zswap_entry_free(struct zswap_entry *entry)\nmm/zswap.c-799-{\n--\nmm/zswap.c-817-**********************************/\nmm/zswap.c:818:static int zswap_cpu_comp_prepare(unsigned int cpu, struct hlist_node *node)\nmm/zswap.c-819-{\n--\nmm/zswap.c-874-\nmm/zswap.c:875:static bool zswap_compress(struct page *page, struct zswap_entry *entry,\nmm/zswap.c-876-\t\t\t   struct zswap_pool *pool)\n--\nmm/zswap.c-958-\nmm/zswap.c:959:static bool zswap_decompress(struct zswap_entry *entry, struct folio *folio)\nmm/zswap.c-960-{\n--\nmm/zswap.c-1021- */\nmm/zswap.c:1022:static int zswap_writeback_entry(struct zswap_entry *entry,\nmm/zswap.c-1023-\t\t\t\t swp_entry_t swpentry)\n--\nmm/zswap.c=1343=static void shrink_worker(struct work_struct *w)\n--\nmm/zswap.c-1432-\nmm/zswap.c:1433:static bool zswap_store_page(struct page *page,\nmm/zswap.c-1434-\t\t\t     struct obj_cgroup *objcg,\n--\nmm/zswap.c-1512-\nmm/zswap.c:1513:bool zswap_store(struct folio *folio)\nmm/zswap.c-1514-{\n--\nmm/zswap.c-1618- */\nmm/zswap.c:1619:int zswap_load(struct folio *folio)\nmm/zswap.c-1620-{\n--\nmm/zswap.c-1671-\nmm/zswap.c:1672:void zswap_invalidate(swp_entry_t swp)\nmm/zswap.c-1673-{\n--\nmm/zswap.c-1685-\nmm/zswap.c:1686:int zswap_swapon(int type, unsigned long nr_pages)\nmm/zswap.c-1687-{\n--\nmm/zswap.c-1705-\nmm/zswap.c:1706:void zswap_swapoff(int type)\nmm/zswap.c-1707-{\n--\nmm/zswap.c=1750=DEFINE_DEBUGFS_ATTRIBUTE(stored_incompressible_pages_fops,\n--\nmm/zswap.c-1752-\nmm/zswap.c:1753:static int zswap_debugfs_init(void)\nmm/zswap.c-1754-{\n--\nmm/zswap.c-1786-#else\nmm/zswap.c:1787:static int zswap_debugfs_init(void)\nmm/zswap.c-1788-{\n--\nmm/zswap.c-1795-**********************************/\nmm/zswap.c:1796:static int zswap_setup(void)\nmm/zswap.c-1797-{\n"
}

gemini-3.1-pro-preview

null

null

							input: 8564
							output: 19
							thoughts: 222
						

**Fuzzing Zswap: A Targeted Approach**

Okay, so I'm looking at this zswap code and immediately I see the key entry points for potential fuzzing targets. We've got the non-static API entry points: `zswap_store`, `zswap_load`, `zswap_invalidate`, `zswap_swapon`, and `zswap_swapoff`. Those are the obvious candidates, the ones we can directly interact with.

Now, glancing at the patch, it seems to be touching functions like `zswap_pool_create`, `zswap_pool_destroy`, `zswap_entry_free`, `zswap_decompress`, and `zswap_store_page`. These seem to be mostly static helpers. But I can see the connection now: `zswap_store` is calling `zswap_store_page`. `zswap_load` relies on `zswap_decompress`, and `zswap_invalidate` calls `zswap_entry_free`.

Therefore, the most direct path to effective fuzzing is to focus on `zswap_store`, `zswap_load`, and `zswap_invalidate`. These are the functions that ultimately orchestrate the core operations, and we can test the inputs and conditions from outside. The `zswap_swapon` and `zswap_swapoff` entry points also seem like decent choices to include.

I will take a moment to confirm that `zswap_store` is exported and available, or determine how it can be appropriately invoked. This will then allow for effective fuzzing execution.

{
  "Expression": "zswap_store\\("
}

{
  "Output": "include/linux/zswap.h=27=unsigned long zswap_total_pages(void);\ninclude/linux/zswap.h:28:bool zswap_store(struct folio *folio);\ninclude/linux/zswap.h-29-int zswap_load(struct folio *folio);\n--\ninclude/linux/zswap.h=40=struct zswap_lruvec_state {};\ninclude/linux/zswap.h-41-\ninclude/linux/zswap.h:42:static inline bool zswap_store(struct folio *folio)\ninclude/linux/zswap.h-43-{\n--\nmm/page_io.c=203=int swap_writeout(struct swap_io_ctx *ctx, struct folio *folio)\n--\nmm/page_io.c-236-\nmm/page_io.c:237:\tif (zswap_store(folio)) {\nmm/page_io.c-238-\t\tcount_mthp_stat(folio_order(folio), MTHP_STAT_ZSWPOUT);\n--\nmm/zswap.c=959=static bool zswap_decompress(struct zswap_entry *entry, struct folio *folio)\n--\nmm/zswap.c-1016- * to the swap device.  We are basically resuming the same swap\nmm/zswap.c:1017: * writeback path that was intercepted with the zswap_store()\nmm/zswap.c-1018- * in the first place.  After the folio has been decompressed into\n--\nmm/zswap.c=1433=static bool zswap_store_page(struct page *page,\n--\nmm/zswap.c-1512-\nmm/zswap.c:1513:bool zswap_store(struct folio *folio)\nmm/zswap.c-1514-{\n"
}

gemini-3.1-pro-preview

null

null

							input: 9617
							output: 19
							thoughts: 88
						

Okay, here's my understanding, framed as my internal thought process:

**Zswap Function Calls & Invalidation**

Alright, let's see, my mental map of the zswap interaction within the kernel is being refreshed. I'm focusing on the call flow now. Right, so `zswap_store` is the function responsible for putting pages into the compressed cache, and I remember that's triggered from `swap_writeout` in `mm/page_io.c`. That makes perfect sense; as pages are written out to the swap partition, they're intercepted and potentially compressed in zswap first. Good.

Now, `zswap_load` is obviously the counterpart, pulling pages *from* zswap. And that, as expected, is called from `swap_read_folio`, also in `mm/page_io.c`. That's the read path, right? When the system needs a page from swap, it checks zswap first.

Finally, `zswap_invalidate` is called to remove or clear an entry from the compressed cache, when a page needs to be swapped out, freed, or otherwise removed from the swap partition. I know that's triggered from `swap_free` or a similar swap-related function. Good.

So, where do I start digging in to see how its working? I'm going to take a closer look at `zswap_load` and then `zswap_invalidate`, to remind myself how those functions work. I need to be sure that I am up to speed with any changes.

{
  "Expression": "zswap_load\\("
}

{
  "Output": "include/linux/zswap.h=28=bool zswap_store(struct folio *folio);\ninclude/linux/zswap.h:29:int zswap_load(struct folio *folio);\ninclude/linux/zswap.h-30-void zswap_invalidate(swp_entry_t swp);\n--\ninclude/linux/zswap.h=42=static inline bool zswap_store(struct folio *folio)\n--\ninclude/linux/zswap.h-46-\ninclude/linux/zswap.h:47:static inline int zswap_load(struct folio *folio)\ninclude/linux/zswap.h-48-{\n--\nmm/page_io.c=451=void swap_read_folio(struct swap_io_ctx *ctx, struct folio *folio)\n--\nmm/page_io.c-478-\nmm/page_io.c:479:\tif (zswap_load(folio) != -ENOENT)\nmm/page_io.c-480-\t\tgoto finish;\n--\nmm/zswap.c=1513=bool zswap_store(struct folio *folio)\n--\nmm/zswap.c-1599-/**\nmm/zswap.c:1600: * zswap_load() - load a folio from zswap\nmm/zswap.c-1601- * @folio: folio to load\n--\nmm/zswap.c-1618- */\nmm/zswap.c:1619:int zswap_load(struct folio *folio)\nmm/zswap.c-1620-{\n"
}

gemini-3.1-pro-preview

null

null

							input: 10462
							output: 19
							thoughts: 7
						

Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person:

**Navigating the `zswap_invalidate` Function**

Alright, I'm diving into the `zswap_invalidate` function. My initial thought is to immediately situate it within the larger context of zswap's operation, particularly memory management and data integrity. I know this is crucial for ensuring that compressed data residing in zswap doesn't lead to inconsistencies or corruption within the overall system memory. I immediately think about the interaction with the page cache, swap cache and how it relates to reclaim. I'm imagining scenarios involving page faults, writeback, and the potential need to discard or re-read data when the zswap backing store needs to be invalidated.

I'm probably going to be mentally stepping through its likely responsibilities: invalidating zswap entries for pages that are no longer valid in physical memory, cleaning up the compressed data structures and potentially freeing up space within the zswap pool. I'm going to want to understand its interaction with the page tables, particularly how it affects the translation between virtual and physical addresses when pages get re-accessed or removed. Specifically, the function probably handles the delicate balance between compressed data being present on disk, and the underlying pages still being valid.

I'm expecting to look for potential concurrency issues – what happens with multiple processes concurrently accessing the same pages or the zswap pool? Are there locks involved? How are race conditions handled to prevent data corruption? What about interrupt handlers?

I'll be paying close attention to any error handling or safety checks. I'm hoping to see well-defined error paths and robust mechanisms to deal with unexpected situations. Specifically, I'm thinking about the return values and what they signal. And how it handles conditions like out-of-memory or corruption. I know the devil is often in the details when dealing with low-level memory management like this, so I will start by tracing what happens during a `zswap_invalidate` call.

{
  "Expression": "zswap_invalidate\\("
}

{
  "Output": "include/linux/zswap.h=29=int zswap_load(struct folio *folio);\ninclude/linux/zswap.h:30:void zswap_invalidate(swp_entry_t swp);\ninclude/linux/zswap.h-31-int zswap_swapon(int type, unsigned long nr_pages);\n--\ninclude/linux/zswap.h=47=static inline int zswap_load(struct folio *folio)\n--\ninclude/linux/zswap.h-51-\ninclude/linux/zswap.h:52:static inline void zswap_invalidate(swp_entry_t swp) {}\ninclude/linux/zswap.h-53-static inline int zswap_swapon(int type, unsigned long nr_pages)\n--\nmm/swapfile.c=1316=static void swap_range_free(struct swap_info_struct *si, unsigned long offset,\n--\nmm/swapfile.c-1323-\tfor (i = 0; i \u003c nr_entries; i++)\nmm/swapfile.c:1324:\t\tzswap_invalidate(swp_entry(si-\u003etype, offset + i));\nmm/swapfile.c-1325-\n--\nmm/zswap.c=1619=int zswap_load(struct folio *folio)\n--\nmm/zswap.c-1671-\nmm/zswap.c:1672:void zswap_invalidate(swp_entry_t swp)\nmm/zswap.c-1673-{\n"
}

gemini-3.1-pro-preview

null

null

							input: 11304
							output: 19
							thoughts: 138
						

**My Assessment of the Zswap Patch**

Okay, so I've got this zswap patch in front of me, and my immediate focus is on which symbols are critical for understanding its impact and, therefore, which ones I need to target with fuzzing. Specifically, I need to make sure I'm zeroing in on: `zswap_store`, `zswap_load`, `zswap_invalidate`, `zswap_swapon`, and `zswap_swapoff`. These are the core functions that will illustrate the changes.

Functionally, I understand that the patch is altering how zswap entries store the pool reference, which is a key structural shift. Replacing the pointer with an index into an xarray is definitely worth some serious fuzzing. The ramifications could be significant, and I want to expose any potential edge cases or vulnerabilities here.

Now, before I dig into fuzzing, I want to confirm I've got all the necessary configurations enabled to properly test this patch. I need to double-check that `CONFIG_ZSWAP` and `CONFIG_ZSWAP_DEFAULT_ON` are set correctly, and that `CONFIG_SWAP`, as the parent config, is also properly enabled. Are there any other hidden dependencies I need to be aware of? Best to be thorough upfront to avoid wasting time later.

{
  "Expression": "depends on ZSWAP"
}

{
  "Output": "mm/Kconfig=35=config ZSWAP_DEFAULT_ON\nmm/Kconfig-36-\tbool \"Enable the compressed cache for swap pages by default\"\nmm/Kconfig:37:\tdepends on ZSWAP\nmm/Kconfig-38-\thelp\n--\nmm/Kconfig=45=config ZSWAP_SHRINKER_DEFAULT_ON\nmm/Kconfig-46-\tbool \"Shrink the zswap pool on memory pressure\"\nmm/Kconfig:47:\tdepends on ZSWAP\nmm/Kconfig-48-\tdefault n\n--\nmm/Kconfig=59=choice\nmm/Kconfig-60-\tprompt \"Default compressor\"\nmm/Kconfig:61:\tdepends on ZSWAP\nmm/Kconfig-62-\tdefault ZSWAP_COMPRESSOR_DEFAULT_LZO\n--\nmm/Kconfig=114=config ZSWAP_COMPRESSOR_DEFAULT\nmm/Kconfig-115-       string\nmm/Kconfig:116:       depends on ZSWAP\nmm/Kconfig-117-       default \"deflate\" if ZSWAP_COMPRESSOR_DEFAULT_DEFLATE\n"
}

gemini-3.1-pro-preview

null

null

							input: 12035
							output: 20
							thoughts: 41
						

Okay, here's my take on those concepts, putting myself in the thought process:

**Diving into ZSWAP and Related Functions**

Alright, let's get down to the core of this. When we're talking about zswap, the two big players that immediately come to mind are `ZSWAP` itself and `ZSWAP_DEFAULT_ON`. Those are the fundamental flags that control its behavior, the main levers we have to pull.

Now, where do those levers connect? We need to look at the functions that actually *do* something with zswap. I'd better check `zswap_swapon` and `zswap_swapoff`. They're the critical endpoints – the entry and exit points, the on/off switches that make zswap active or inactive. I need to understand how they work, how they're implemented, and what dependencies they have. Knowing the control points will give me a better understanding of the wider architecture. I’ll need to trace the implications of enabling or disabling ZSWAP and consider the wider system effects.

{
  "Expression": "zswap_swapon\\("
}

{
  "Output": "include/linux/zswap.h=30=void zswap_invalidate(swp_entry_t swp);\ninclude/linux/zswap.h:31:int zswap_swapon(int type, unsigned long nr_pages);\ninclude/linux/zswap.h-32-void zswap_swapoff(int type);\n--\ninclude/linux/zswap.h=52=static inline void zswap_invalidate(swp_entry_t swp) {}\ninclude/linux/zswap.h:53:static inline int zswap_swapon(int type, unsigned long nr_pages)\ninclude/linux/zswap.h-54-{\n--\nmm/swapfile.c=3606=SYSCALL_DEFINE2(swapon, const char __user *, specialfile, int, swap_flags)\n--\nmm/swapfile.c-3758-\nmm/swapfile.c:3759:\terror = zswap_swapon(si-\u003etype, maxpages);\nmm/swapfile.c-3760-\tif (error)\n--\nmm/zswap.c=1672=void zswap_invalidate(swp_entry_t swp)\n--\nmm/zswap.c-1685-\nmm/zswap.c:1686:int zswap_swapon(int type, unsigned long nr_pages)\nmm/zswap.c-1687-{\n"
}

gemini-3.1-pro-preview

null

null

							input: 12680
							output: 21
							thoughts: 217
						

**My Analysis of Zswap Patch Focus**

Okay, so the text is guiding me towards focusing my fuzzing efforts on specific zswap functions, and I understand why. The context tells me that `swapon` and `swapoff` syscalls are the primary entry points to consider. This points me to key symbols: `zswap_store`, `zswap_load`, `zswap_invalidate`, `zswap_swapon`, and `zswap_swapoff`. These are the obvious points where the modified index-based pool lookup and its lifetime management would be most likely to expose bugs.

The core of the patch revolves around changing how the zswap entry, specifically the pool pointer, is handled. Now, it's an `u16` index mapped using an xarray. This change fundamentally impacts how pools are created, destroyed, and how entries within the pool are allocated and freed. The provided reasoning makes perfect sense: fuzzing these main entry points—the critical path functions—is paramount to ensure the new pool lookup and lifetime management operate correctly.

I'll need to confirm that `zswap_pool_create` and `zswap_pool_destroy` are indeed reachable from the functions. I'm thinking about it now. `zswap_pool_create`, for instance, is likely called when a new pool is needed, perhaps when the compressor algorithm changes or during initialization. I'll take a close look at `zswap_pool_create` to confirm how it interacts with the more core functions.

{
  "Expression": "zswap_pool_create\\("
}

{
  "Output": "mm/zswap.c=267=static void acomp_ctx_free(struct crypto_acomp_ctx *acomp_ctx)\n--\nmm/zswap.c-294-\nmm/zswap.c:295:static struct zswap_pool *zswap_pool_create(char *compressor)\nmm/zswap.c-296-{\n--\nmm/zswap.c=375=static struct zswap_pool *__zswap_pool_create_fallback(void)\n--\nmm/zswap.c-390-\nmm/zswap.c:391:\treturn zswap_pool_create(zswap_compressor);\nmm/zswap.c-392-}\n--\nmm/zswap.c=561=static int zswap_compressor_param_set(const char *val, const struct kernel_param *kp)\n--\nmm/zswap.c-603-\tif (!pool)\nmm/zswap.c:604:\t\tpool = zswap_pool_create(s);\nmm/zswap.c-605-\telse {\n"
}

gemini-3.1-pro-preview

null

null

							input: 13523
							output: 152
							thoughts: 157
						

**My Zswap Fuzzing Strategy**

Okay, so I'm thinking about how to effectively fuzz the zswap functionality. From what I'm seeing, the `zswap_pool_create` function is key. It's the point where the memory pool for zswap is initialized, and crucially, it's called in a couple of interesting scenarios. First, it's triggered when someone changes the compressor via sysfs using `zswap_compressor_param_set`. Second, and probably more frequently, it's called through `__zswap_pool_create_fallback` if the pool doesn't already exist and the system attempts to store a swap entry via `zswap_store`.

This tells me fuzzing `zswap_store` is a good starting point to trigger `zswap_pool_create`. It's a direct path to exercising that initialization code. And, as a secondary entrypoint, I can use the sysfs callback mechanism of `zswap_compressor_param_set` by writing to `/sys/module/zswap/parameters/compressor`. This should give me another, somewhat controlled, way to call that initialization function.

Therefore, my initial fuzzer setup will definitely include `zswap_store`. I will also incorporate `zswap_load`, `zswap_invalidate`, `zswap_swapon` and `zswap_swapoff`. These are the core zswap functions that handle data movement and management within the swap space. I'll need to explore the interaction between these, as `zswap_store` doesn't exist in isolation; it has to be paired with `zswap_load` (or at least used to setup state to trigger these functions).

Ultimately, I'm expecting this to be a set-results approach, where I can monitor the behavior of the system and see if anything is amiss.

{
  "EnableConfigs": [
    "ZSWAP",
    "ZSWAP_DEFAULT_ON"
  ],
  "FocusSymbols": [
    "zswap_store",
    "zswap_load",
    "zswap_invalidate",
    "zswap_swapon",
    "zswap_swapoff"
  ],
  "Reasoning": "The patch modifies the core zswap logic by replacing the pool pointer in zswap_entry with a u16 index mapped via an xarray. This affects pool creation, destruction, entry allocation, and freeing. Fuzzing should focus on the main zswap entry points to ensure the new index-based pool lookup and lifetime management are correct.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "ZSWAP",
    "ZSWAP_DEFAULT_ON"
  ],
  "FocusSymbols": [
    "zswap_store",
    "zswap_load",
    "zswap_invalidate",
    "zswap_swapon",
    "zswap_swapoff"
  ],
  "Reasoning": "The patch modifies the core zswap logic by replacing the pool pointer in zswap_entry with a u16 index mapped via an xarray. This affects pool creation, destruction, entry allocation, and freeing. Fuzzing should focus on the main zswap entry points to ensure the new index-based pool lookup and lifetime management are correct.",
  "WorthFuzzing": true
}