AI Trajectory

null

{
  "EnableConfigs": [
    "EROFS_FS",
    "EROFS_FS_BACKED_BY_FILE"
  ],
  "FocusSymbols": [
    "erofs_fc_get_tree",
    "erofs_fc_test_file_super"
  ],
  "Reasoning": "The patch modifies the EROFS mount path to allow sharing superblocks when mounting from the same backing file. This is a functional change in the filesystem's core logic, reachable from userspace via mount syscalls, and should be fuzzed to ensure no concurrency or lifecycle bugs (e.g., use-after-free) occur during superblock sharing.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 9ca72259ec8cd88e26f5adb04a8103add776c6ab\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Sat Aug 1 01:07:40 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/Documentation/filesystems/erofs.rst b/Documentation/filesystems/erofs.rst\nindex 774e8b236d099..ef6785035b26a 100644\n--- a/Documentation/filesystems/erofs.rst\n+++ b/Documentation/filesystems/erofs.rst\n@@ -154,6 +154,10 @@ Only regular files are accepted as backing files; to mount an image that\n resides on a block device, use the traditional block device mount path\n instead.\n \n+When the same backing file is mounted more than once with compatible\n+mount options, the kernel reuses the existing superblock.  If mount\n+options conflict, a separate superblock is created transparently.\n+\n Sysfs Entries\n =============\n \ndiff --git a/fs/erofs/super.c b/fs/erofs/super.c\nindex 8ead1646f3294..964a0a5e5f300 100644\n--- a/fs/erofs/super.c\n+++ b/fs/erofs/super.c\n@@ -779,6 +779,46 @@ static int erofs_fc_fill_super(struct super_block *sb, struct fs_context *fc)\n \treturn 0;\n }\n \n+static int erofs_fc_test_file_super(struct super_block *sb,\n+\t\t\t\t    struct fs_context *fc)\n+{\n+\tstruct erofs_sb_info *sbi = EROFS_SB(sb);\n+\tstruct erofs_sb_info *new_sbi = fc-\u003es_fs_info;\n+\n+\tif (sb-\u003es_iflags \u0026 SB_I_RETIRED)\n+\t\treturn 0;\n+\tif (!sbi-\u003edif0.file || !new_sbi-\u003edif0.file)\n+\t\treturn 0;\n+\treturn file_inode(sbi-\u003edif0.file) == file_inode(new_sbi-\u003edif0.file) \u0026\u0026\n+\t       sbi-\u003edif0.fsoff == new_sbi-\u003edif0.fsoff \u0026\u0026\n+\t       sbi-\u003eopt.mount_opt == new_sbi-\u003eopt.mount_opt \u0026\u0026\n+\t       sbi-\u003eopt.cache_strategy == new_sbi-\u003eopt.cache_strategy;\n+}\n+\n+static int erofs_fc_get_tree_file(struct fs_context *fc)\n+{\n+\tstruct super_block *sb;\n+\tint err;\n+\n+\tsb = sget_fc(fc, erofs_fc_test_file_super, set_anon_super_fc);\n+\tif (IS_ERR(sb))\n+\t\treturn PTR_ERR(sb);\n+\n+\tif (!sb-\u003es_root) {\n+\t\terr = erofs_fc_fill_super(sb, fc);\n+\t\tif (err) {\n+\t\t\tdeactivate_locked_super(sb);\n+\t\t\treturn err;\n+\t\t}\n+\t\tsb-\u003es_flags |= SB_ACTIVE;\n+\t} else {\n+\t\terofs_info(sb, \"sharing superblock for the same backing file\");\n+\t}\n+\n+\tfc-\u003eroot = dget(sb-\u003es_root);\n+\treturn 0;\n+}\n+\n static int erofs_fc_get_tree(struct fs_context *fc)\n {\n \tstruct erofs_sb_info *sbi = fc-\u003es_fs_info;\n@@ -794,7 +834,7 @@ static int erofs_fc_get_tree(struct fs_context *fc)\n \t\t\terrorfc(fc, \"source is unsupported\");\n \t\t\treturn -EINVAL;\n \t\t}\n-\t\treturn get_tree_nodev(fc, erofs_fc_fill_super);\n+\t\treturn erofs_fc_get_tree_file(fc);\n \t}\n \n \tret = get_tree_bdev_flags(fc, erofs_fc_fill_super,\n@@ -812,7 +852,7 @@ static int erofs_fc_get_tree(struct fs_context *fc)\n \n \t\tif (S_ISREG(file_inode(sbi-\u003edif0.file)-\u003ei_mode) \u0026\u0026\n \t\t    sbi-\u003edif0.file-\u003ef_mapping-\u003ea_ops-\u003eread_folio)\n-\t\t\treturn get_tree_nodev(fc, erofs_fc_fill_super);\n+\t\t\treturn erofs_fc_get_tree_file(fc);\n \t}\n \treturn ret;\n }\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "EROFS_FS",
    "EROFS_FS_BACKED_BY_FILE"
  ],
  "FocusSymbols": [
    "erofs_fc_get_tree",
    "erofs_fc_test_file_super"
  ],
  "Reasoning": "The patch modifies the EROFS mount path to allow sharing superblocks when mounting from the same backing file. This is a functional change in the filesystem's core logic, reachable from userspace via mount syscalls, and should be fuzzed to ensure no concurrency or lifecycle bugs (e.g., use-after-free) occur during superblock sharing.",
  "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 9ca72259ec8cd88e26f5adb04a8103add776c6ab
Author: syz-cluster <triage@syzkaller.com>
Date:   Sat Aug 1 01:07:40 2026 +0000

    syz-cluster: applied patch under review

diff --git a/Documentation/filesystems/erofs.rst b/Documentation/filesystems/erofs.rst
index 774e8b236d099..ef6785035b26a 100644
--- a/Documentation/filesystems/erofs.rst
+++ b/Documentation/filesystems/erofs.rst
@@ -154,6 +154,10 @@ Only regular files are accepted as backing files; to mount an image that
 resides on a block device, use the traditional block device mount path
 instead.
 
+When the same backing file is mounted more than once with compatible
+mount options, the kernel reuses the existing superblock.  If mount
+options conflict, a separate superblock is created transparently.
+
 Sysfs Entries
 =============
 
diff --git a/fs/erofs/super.c b/fs/erofs/super.c
index 8ead1646f3294..964a0a5e5f300 100644
--- a/fs/erofs/super.c
+++ b/fs/erofs/super.c
@@ -779,6 +779,46 @@ static int erofs_fc_fill_super(struct super_block *sb, struct fs_context *fc)
 	return 0;
 }
 
+static int erofs_fc_test_file_super(struct super_block *sb,
+				    struct fs_context *fc)
+{
+	struct erofs_sb_info *sbi = EROFS_SB(sb);
+	struct erofs_sb_info *new_sbi = fc->s_fs_info;
+
+	if (sb->s_iflags & SB_I_RETIRED)
+		return 0;
+	if (!sbi->dif0.file || !new_sbi->dif0.file)
+		return 0;
+	return file_inode(sbi->dif0.file) == file_inode(new_sbi->dif0.file) &&
+	       sbi->dif0.fsoff == new_sbi->dif0.fsoff &&
+	       sbi->opt.mount_opt == new_sbi->opt.mount_opt &&
+	       sbi->opt.cache_strategy == new_sbi->opt.cache_strategy;
+}
+
+static int erofs_fc_get_tree_file(struct fs_context *fc)
+{
+	struct super_block *sb;
+	int err;
+
+	sb = sget_fc(fc, erofs_fc_test_file_super, set_anon_super_fc);
+	if (IS_ERR(sb))
+		return PTR_ERR(sb);
+
+	if (!sb->s_root) {
+		err = erofs_fc_fill_super(sb, fc);
+		if (err) {
+			deactivate_locked_super(sb);
+			return err;
+		}
+		sb->s_flags |= SB_ACTIVE;
+	} else {
+		erofs_info(sb, "sharing superblock for the same backing file");
+	}
+
+	fc->root = dget(sb->s_root);
+	return 0;
+}
+
 static int erofs_fc_get_tree(struct fs_context *fc)
 {
 	struct erofs_sb_info *sbi = fc->s_fs_info;
@@ -794,7 +834,7 @@ static int erofs_fc_get_tree(struct fs_context *fc)
 			errorfc(fc, "source is unsupported");
 			return -EINVAL;
 		}
-		return get_tree_nodev(fc, erofs_fc_fill_super);
+		return erofs_fc_get_tree_file(fc);
 	}
 
 	ret = get_tree_bdev_flags(fc, erofs_fc_fill_super,
@@ -812,7 +852,7 @@ static int erofs_fc_get_tree(struct fs_context *fc)
 
 		if (S_ISREG(file_inode(sbi->dif0.file)->i_mode) &&
 		    sbi->dif0.file->f_mapping->a_ops->read_folio)
-			return get_tree_nodev(fc, erofs_fc_fill_super);
+			return erofs_fc_get_tree_file(fc);
 	}
 	return ret;
 }

gemini-3.1-pro-preview

null

null

							input: 2951
							output: 31
							thoughts: 163
						

**Analyzing the EROFS Patch for File-Backed Images**

Okay, so I've got this patch here that's making changes to the EROFS filesystem, specifically in `fs/erofs/super.c` and `Documentation/filesystems/erofs.rst`. Looks like it's introducing some new functions: `erofs_fc_test_file_super` and `erofs_fc_get_tree_file`, and it's modifying `erofs_fc_get_tree` to use that new `erofs_fc_get_tree_file` instead of `get_tree_nodev`. Ah, this is a functional change, a pretty significant one. This seems focused on how EROFS is mounting file-backed images, right? The intention is to enable sharing a superblock for the same backing file – which is a pretty clever optimization.

Now, before I dig into the code, I need to understand the configuration implications. I need to figure out what config options are affected by this change. Let's use `git grep` to quickly identify any relevant EROFS config options. Knowing the config options will help me understand the impact of the patch on different builds and deployment scenarios. Time to see what options need to be enabled or disabled, or maybe if any new ones are being introduced.

{
  "Expression": "config EROFS",
  "PathPrefix": "fs/erofs/Kconfig"
}

{
  "Output": "fs/erofs/Kconfig-2-\nfs/erofs/Kconfig:3:config EROFS_FS\nfs/erofs/Kconfig-4-\ttristate \"EROFS filesystem support\"\n--\nfs/erofs/Kconfig-49-\nfs/erofs/Kconfig:50:config EROFS_FS_DEBUG\nfs/erofs/Kconfig-51-\tbool \"EROFS debugging feature\"\n--\nfs/erofs/Kconfig-59-\nfs/erofs/Kconfig:60:config EROFS_FS_XATTR\nfs/erofs/Kconfig-61-\tbool \"EROFS extended attributes\"\n--\nfs/erofs/Kconfig-70-\nfs/erofs/Kconfig:71:config EROFS_FS_POSIX_ACL\nfs/erofs/Kconfig-72-\tbool \"EROFS Access Control Lists\"\n--\nfs/erofs/Kconfig-84-\nfs/erofs/Kconfig:85:config EROFS_FS_SECURITY\nfs/erofs/Kconfig-86-\tbool \"EROFS Security Labels\"\n--\nfs/erofs/Kconfig-97-\nfs/erofs/Kconfig:98:config EROFS_FS_BACKED_BY_FILE\nfs/erofs/Kconfig-99-\tbool \"File-backed EROFS filesystem support\"\n--\nfs/erofs/Kconfig-111-\nfs/erofs/Kconfig:112:config EROFS_FS_ZIP\nfs/erofs/Kconfig-113-\tbool \"EROFS Data Compression Support\"\n--\nfs/erofs/Kconfig-121-\nfs/erofs/Kconfig:122:config EROFS_FS_ZIP_LZMA\nfs/erofs/Kconfig-123-\tbool \"EROFS LZMA compressed data support\"\n--\nfs/erofs/Kconfig-133-\nfs/erofs/Kconfig:134:config EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS\nfs/erofs/Kconfig-135-\tint \"EROFS LZMA default maximum decompression streams\"\n--\nfs/erofs/Kconfig-147-\nfs/erofs/Kconfig:148:config EROFS_FS_ZIP_DEFLATE\nfs/erofs/Kconfig-149-\tbool \"EROFS DEFLATE compressed data support\"\n--\nfs/erofs/Kconfig-158-\nfs/erofs/Kconfig:159:config EROFS_FS_ZIP_ZSTD\nfs/erofs/Kconfig-160-\tbool \"EROFS Zstandard compressed data support\"\n--\nfs/erofs/Kconfig-169-\nfs/erofs/Kconfig:170:config EROFS_FS_ZIP_ACCEL\nfs/erofs/Kconfig-171-\tbool \"EROFS hardware decompression support\"\n--\nfs/erofs/Kconfig-183-\nfs/erofs/Kconfig:184:config EROFS_FS_PCPU_KTHREAD\nfs/erofs/Kconfig-185-\tbool \"EROFS per-cpu decompression kthread workers\"\n--\nfs/erofs/Kconfig-192-\nfs/erofs/Kconfig:193:config EROFS_FS_PCPU_KTHREAD_HIPRI\nfs/erofs/Kconfig-194-\tbool \"EROFS high priority per-CPU kthread workers\"\n--\nfs/erofs/Kconfig-202-\nfs/erofs/Kconfig:203:config EROFS_FS_PAGE_CACHE_SHARE\nfs/erofs/Kconfig-204-\tbool \"EROFS page cache share support (experimental)\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 4353
							output: 40
							thoughts: 52
						

Okay, here's my take on those thoughts, framed as my own:

**EROFS Superblock Reuse Deep Dive**

Alright, this patch caught my eye because of that key phrase: "When the same backing file is mounted more than once with compatible mount options, the kernel reuses the existing superblock." That immediately flags a connection to `EROFS_FS_BACKED_BY_FILE`. I'm curious to see how this works. I need to understand this better. Now, the logical next step is to drill down into the dependencies of `EROFS_FS_BACKED_BY_FILE`. What other kernel features or configurations is this behavior reliant upon? I'll need to trace through the relevant code paths to get a clear picture of its implications and potential edge cases. Time to dig in!

{
  "Expression": "config EROFS_FS_BACKED_BY_FILE",
  "PathPrefix": "fs/erofs/Kconfig"
}

{
  "Output": "fs/erofs/Kconfig=85=config EROFS_FS_SECURITY\n--\nfs/erofs/Kconfig-97-\nfs/erofs/Kconfig:98:config EROFS_FS_BACKED_BY_FILE\nfs/erofs/Kconfig-99-\tbool \"File-backed EROFS filesystem support\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 4709
							output: 34
							thoughts: 19
						

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

**Diving into EROFS Configuration**

Okay, so I need to understand how some aspect of EROFS is configured. My initial instinct is to go straight to the configuration file – specifically, the `Kconfig` file within the EROFS filesystem directory. Let's start with `fs/erofs/Kconfig` and, given my general familiarity with these files, I'll start looking around line 98. That feels like a reasonable point to begin; that line likely covers a specific feature or option I'm trying to identify. Time to get my eyes on that file.

{
  "File": "fs/erofs/Kconfig",
  "FirstLine": 90,
  "LineCount": 20
}

{
  "Contents": "  90:\t\t  Security labels provide an access control facility to support Linux\n  91:\t\t  Security Models (LSMs) accepted by AppArmor, SELinux, Smack and TOMOYO\n  92:\t\t  Linux. This option enables an extended attribute handler for file\n  93:\t\t  security labels in the erofs filesystem, so that it requires enabling\n  94:\t\t  the extended attribute support in advance.\n  95:\t\n  96:\t\t  If you are not using a security module, say N.\n  97:\t\n  98:\tconfig EROFS_FS_BACKED_BY_FILE\n  99:\t\tbool \"File-backed EROFS filesystem support\"\n 100:\t\tdepends on EROFS_FS\n 101:\t\tdefault y\n 102:\t\thelp\n 103:\t\t  This allows EROFS to use filesystem image files directly, without\n 104:\t\t  the intercession of loopback block devices or likewise. It is\n 105:\t\t  particularly useful for container images with numerous blobs and\n 106:\t\t  other sandboxes, where loop devices behave intricately.  It can also\n 107:\t\t  be used to simplify error-prone lifetime management of unnecessary\n 108:\t\t  virtual block devices.\n 109:\t\n"
}

gemini-3.1-pro-preview

null

null

							input: 5232
							output: 36
							thoughts: 194
						

**Analyzing the EROFS Filesystem Configuration for Fuzzing**

Okay, so I'm looking at these configurations, `EROFS_FS` and `EROFS_FS_BACKED_BY_FILE`, and I need to determine the scope for fuzzing after this patch. From what I can tell, the main functions modified are `erofs_fc_test_file_super`, `erofs_fc_get_tree_file`, and `erofs_fc_get_tree`.

I need to confirm that these are the only relevant functions, but I'm going to start by analyzing the primary entry points. The patch impacts `erofs_fc_get_tree`, which I know is the mount entry point. `erofs_fc_test_file_super` and `erofs_fc_get_tree_file` are specifically static functions called by `erofs_fc_get_tree`. So, realistically, `erofs_fc_get_tree` is the central symbol of interest here.

Now, let me just double-check that `erofs_fc_get_tree` isn't static. It's crucial that it's accessible externally if it's the main entry point to the affected functionality.

{
  "Expression": "erofs_fc_get_tree",
  "PathPrefix": "fs/erofs/super.c"
}

{
  "Output": "fs/erofs/super.c=782=static int erofs_fc_test_file_super(struct super_block *sb,\n--\nfs/erofs/super.c-797-\nfs/erofs/super.c:798:static int erofs_fc_get_tree_file(struct fs_context *fc)\nfs/erofs/super.c-799-{\n--\nfs/erofs/super.c-821-\nfs/erofs/super.c:822:static int erofs_fc_get_tree(struct fs_context *fc)\nfs/erofs/super.c-823-{\n--\nfs/erofs/super.c-836-\t\t}\nfs/erofs/super.c:837:\t\treturn erofs_fc_get_tree_file(fc);\nfs/erofs/super.c-838-\t}\n--\nfs/erofs/super.c-854-\t\t    sbi-\u003edif0.file-\u003ef_mapping-\u003ea_ops-\u003eread_folio)\nfs/erofs/super.c:855:\t\t\treturn erofs_fc_get_tree_file(fc);\nfs/erofs/super.c-856-\t}\n--\nfs/erofs/super.c=932=static const struct fs_context_operations erofs_context_ops = {\nfs/erofs/super.c-933-\t.parse_param\t= erofs_fc_parse_param,\nfs/erofs/super.c:934:\t.get_tree       = erofs_fc_get_tree,\nfs/erofs/super.c-935-\t.reconfigure    = erofs_fc_reconfigure,\n"
}

gemini-3.1-pro-preview

null

null

							input: 6167
							output: 36
							thoughts: 277
						

**Analyzing the EROFS File System Patch**

Okay, so I'm looking at this EROFS file system patch. My initial thought is to figure out the key entry points. `erofs_fc_get_tree` caught my eye, because it's marked as static, but it's assigned to the `.get_tree` field within `erofs_context_ops`. That seems like a potential point of focus. I need to be careful though. Is there any other function that might be a better candidate, like `erofs_fc_fill_super`?

The patch itself introduces `erofs_fc_test_file_super` and `erofs_fc_get_tree_file`, which I'll have to investigate in context. Now, I'm second-guessing myself about `erofs_fc_get_tree`. Since it's static, there's always the possibility of it being inlined by the compiler, which would make it a poor symbol to focus on. But wait...it's assigned to a function pointer, which means the compiler can't inline it fully, it has to have a distinct address. Alright, I'm thinking it's still probably the best entry point for this particular logic.

But let's pause and remember the guidelines. The instructions say, "Prefer non-static, non-inlined API entrypoint functions over internal static helper functions". Good point. Since `erofs_fc_get_tree` *is* assigned to a function pointer, its address is actually taken. So, yes, it *can't* be fully inlined! There has to be a standalone copy.

So, let's back up and make sure I haven't missed any other options. Let's see...is there anything else that sets up `erofs_context_ops`? Ah, here we go, `erofs_init_fs_context` is the function that defines that context.

{
  "Expression": "erofs_init_fs_context",
  "PathPrefix": "fs/erofs/super.c"
}

{
  "Output": "fs/erofs/super.c=932=static const struct fs_context_operations erofs_context_ops = {\n--\nfs/erofs/super.c-938-\nfs/erofs/super.c:939:static int erofs_init_fs_context(struct fs_context *fc)\nfs/erofs/super.c-940-{\n--\nfs/erofs/super.c=999=static struct file_system_type erofs_fs_type = {\n--\nfs/erofs/super.c-1001-\t.name           = \"erofs\",\nfs/erofs/super.c:1002:\t.init_fs_context = erofs_init_fs_context,\nfs/erofs/super.c-1003-\t.kill_sb        = erofs_kill_sb,\n"
}

gemini-3.1-pro-preview

null

null

							input: 7121
							output: 29
							thoughts: 319
						

**My Assessment of the EROFS Filesystem Code**

Okay, let's take a look at this. I see that `erofs_init_fs_context` is declared static, and that's expected. Also, `erofs_kill_sb` is static as well. In general, filesystem driver functions are mostly static and typically assigned to those crucial `ops` structs. So, `erofs_fc_get_tree` seems like a perfectly valid symbol to focus on; it's the core function that's been modified, and the fact that it's in an `ops` struct means it won't be inlined. That's good for analysis.

I should also check if `erofs_fc_fill_super` is static. Alright, yes, it is. The gist is that this patch changes how EROFS handles mounting the same backing file multiple times. That's interesting; it's reachable through the `mount()` syscall using EROFS and a file descriptor. Definitely fuzz-worthy.

Now, for enabling the correct configs, I'll need `EROFS_FS` and `EROFS_FS_BACKED_BY_FILE`. Let me double-check for any other related configs, just to be sure. Nope, `EROFS_FS_BACKED_BY_FILE` just depends on `EROFS_FS`, nothing else. Good.

I should verify that `erofs_fc_get_tree_file` and that `sbi->dif0.file` is conditionally compiled under `#ifdef CONFIG_EROFS_FS_BACKED_BY_FILE` in `fs/erofs/super.c`. Okay, the latter, `sbi->dif0.file` is used. Let me go check if it is conditional.

{
  "Expression": "dif0\\.file",
  "PathPrefix": "fs/erofs/"
}

{
  "Output": "fs/erofs/data.c=67=int erofs_init_metabuf(struct erofs_buf *buf, struct super_block *sb,\n--\nfs/erofs/data.c-80-\tif (erofs_is_fileio_mode(sbi)) {\nfs/erofs/data.c:81:\t\tbuf-\u003efile = sbi-\u003edif0.file;\t/* some fs like FUSE needs it */\nfs/erofs/data.c-82-\t\tbuf-\u003emapping = buf-\u003efile-\u003ef_mapping;\n--\nfs/erofs/internal.h=164=static inline bool erofs_is_fileio_mode(struct erofs_sb_info *sbi)\nfs/erofs/internal.h-165-{\nfs/erofs/internal.h:166:\treturn IS_ENABLED(CONFIG_EROFS_FS_BACKED_BY_FILE) \u0026\u0026 sbi-\u003edif0.file;\nfs/erofs/internal.h-167-}\n--\nfs/erofs/super.c=442=static int erofs_fc_parse_source(struct fs_context *fc,\n--\nfs/erofs/super.c-446-\nfs/erofs/super.c:447:\tif (fc-\u003esource || sbi-\u003edif0.file)\nfs/erofs/super.c-448-\t\treturn invalf(fc, \"Multiple sources\");\n--\nfs/erofs/super.c-466-\t\t\treturn -ENOMEM;\nfs/erofs/super.c:467:\t\tsbi-\u003edif0.file = no_free_ptr(param-\u003efile);\nfs/erofs/super.c-468-\t\treturn 0;\n--\nfs/erofs/super.c=636=static int erofs_fc_fill_super(struct super_block *sb, struct fs_context *fc)\n--\nfs/erofs/super.c-672-\t\tif (erofs_is_fileio_mode(sbi)) {\nfs/erofs/super.c:673:\t\t\tinode = file_inode(sbi-\u003edif0.file);\nfs/erofs/super.c-674-\t\t\tif ((inode-\u003ei_sb-\u003es_op == \u0026erofs_sops \u0026\u0026\n--\nfs/erofs/super.c=782=static int erofs_fc_test_file_super(struct super_block *sb,\n--\nfs/erofs/super.c-789-\t\treturn 0;\nfs/erofs/super.c:790:\tif (!sbi-\u003edif0.file || !new_sbi-\u003edif0.file)\nfs/erofs/super.c-791-\t\treturn 0;\nfs/erofs/super.c:792:\treturn file_inode(sbi-\u003edif0.file) == file_inode(new_sbi-\u003edif0.file) \u0026\u0026\nfs/erofs/super.c-793-\t       sbi-\u003edif0.fsoff == new_sbi-\u003edif0.fsoff \u0026\u0026\n--\nfs/erofs/super.c=822=static int erofs_fc_get_tree(struct fs_context *fc)\n--\nfs/erofs/super.c-826-\nfs/erofs/super.c:827:\tif (sbi-\u003edif0.file) {\nfs/erofs/super.c-828-\t\tif (!IS_ENABLED(CONFIG_EROFS_FS_BACKED_BY_FILE)) {\n--\nfs/erofs/super.c-831-\t\t}\nfs/erofs/super.c:832:\t\tif (!S_ISREG(file_inode(sbi-\u003edif0.file)-\u003ei_mode) ||\nfs/erofs/super.c:833:\t\t    !sbi-\u003edif0.file-\u003ef_mapping-\u003ea_ops-\u003eread_folio) {\nfs/erofs/super.c-834-\t\t\terrorfc(fc, \"source is unsupported\");\n--\nfs/erofs/super.c-850-\t\t\treturn PTR_ERR(file);\nfs/erofs/super.c:851:\t\tsbi-\u003edif0.file = file;\nfs/erofs/super.c-852-\nfs/erofs/super.c:853:\t\tif (S_ISREG(file_inode(sbi-\u003edif0.file)-\u003ei_mode) \u0026\u0026\nfs/erofs/super.c:854:\t\t    sbi-\u003edif0.file-\u003ef_mapping-\u003ea_ops-\u003eread_folio)\nfs/erofs/super.c-855-\t\t\treturn erofs_fc_get_tree_file(fc);\n--\nfs/erofs/super.c=909=static void erofs_sb_free(struct erofs_sb_info *sbi, struct super_block *sb)\n--\nfs/erofs/super.c-912-\tkfree_sensitive(sbi-\u003edomain_id);\nfs/erofs/super.c:913:\tif (sbi-\u003edif0.file)\nfs/erofs/super.c:914:\t\tfput(sbi-\u003edif0.file);\nfs/erofs/super.c-915-\tkfree(sbi-\u003evolume_name);\n--\nfs/erofs/super.c=973=static void erofs_kill_sb(struct super_block *sb)\n--\nfs/erofs/super.c-976-\nfs/erofs/super.c:977:\tif (sbi-\u003edif0.file)\nfs/erofs/super.c-978-\t\tkill_anon_super(sb);\n"
}

gemini-3.1-pro-preview

null

null

							input: 9259
							output: 147
							thoughts: 1054
						

**Analysis of EROFS File-Backed Mounts for Fuzzing**

Okay, so I've been looking at this EROFS patch.  My initial thought is that `CONFIG_EROFS_FS_BACKED_BY_FILE` is dynamically checked within `erofs_fc_get_tree`.  Specifically, if `sbi->dif0.file` is set, and if `EROFS_FS_BACKED_BY_FILE` is *not* enabled, then there's an error.  Therefore, `EROFS_FS_BACKED_BY_FILE` is a prerequisite to hit the new code path.

Since `erofs_fc_get_tree_file` is static, my initial thought is that it might be inlined, but it's called from `erofs_fc_get_tree`, which makes `erofs_fc_get_tree` a key focus symbol. Additionally,  `erofs_fc_test_file_super` is used as a callback function by `sget_fc`.  The address of `erofs_fc_test_file_super` is being passed to `sget_fc`. This means `erofs_fc_test_file_super` is also a critical symbol to focus on because its address is being taken.  Although `erofs_fc_get_tree_file` is static and might be inlined, I'll include both `erofs_fc_get_tree` and `erofs_fc_test_file_super` as focus symbols.

Now, let's verify all the relevant configurations.  We have `EROFS_FS` and `EROFS_FS_BACKED_BY_FILE`.

Looking back at the code, it's clear this patch enables superblock sharing for EROFS filesystems mounted from the same backing file. This introduces new code reachable via `fsopen`, `fsconfig`, and `fsmount` syscalls (or the `mount` system call directly), which means this is a *functional* change in the filesystem mount path.  Given it's in the mount path, I'm thinking concurrent mounts and unmounts are areas that are potentially problematic, leading to use-after-free or race conditions. This should definitely be fuzzed.

In summary, the focus symbols for fuzzing will be `erofs_fc_get_tree` and `erofs_fc_test_file_super`. The key configurations are `EROFS_FS` and `EROFS_FS_BACKED_BY_FILE`.  I should double-check the Kconfig, but I already know `EROFS_FS_BACKED_BY_FILE` depends on `EROFS_FS`. I'm confident in calling `set-results` now.

{
  "EnableConfigs": [
    "EROFS_FS",
    "EROFS_FS_BACKED_BY_FILE"
  ],
  "FocusSymbols": [
    "erofs_fc_get_tree",
    "erofs_fc_test_file_super"
  ],
  "Reasoning": "The patch modifies the EROFS mount path to allow sharing superblocks when mounting from the same backing file. This is a functional change in the filesystem's core logic, reachable from userspace via mount syscalls, and should be fuzzed to ensure no concurrency or lifecycle bugs (e.g., use-after-free) occur during superblock sharing.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "EROFS_FS",
    "EROFS_FS_BACKED_BY_FILE"
  ],
  "FocusSymbols": [
    "erofs_fc_get_tree",
    "erofs_fc_test_file_super"
  ],
  "Reasoning": "The patch modifies the EROFS mount path to allow sharing superblocks when mounting from the same backing file. This is a functional change in the filesystem's core logic, reachable from userspace via mount syscalls, and should be fuzzed to ensure no concurrency or lifecycle bugs (e.g., use-after-free) occur during superblock sharing.",
  "WorthFuzzing": true
}