AI Trajectory

null

{
  "EnableConfigs": [
    "EPOLL"
  ],
  "FocusSymbols": [
    "pipe_set_epoll_usage",
    "pipe_poll"
  ],
  "Reasoning": "The patch modifies the pipe polling logic to only set the epoll usage flag when actually used by epoll (checking filp-\u003ef_ep), rather than any poll usage. This changes the wakeup behavior in anon_pipe_write. This is a functional change to core kernel pipe/epoll interaction.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 067460c3946e60a228df053f61833ff43dafcf8c\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Fri Jul 24 18:41:43 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/fs/pipe.c b/fs/pipe.c\nindex 429b0714ec5755..fa4e70d5f90d89 100644\n--- a/fs/pipe.c\n+++ b/fs/pipe.c\n@@ -357,6 +357,23 @@ static inline unsigned int pipe_update_tail(struct pipe_inode_info *pipe,\n \treturn tail;\n }\n \n+static void pipe_set_epoll_usage(struct file *filp, struct pipe_inode_info *pipe)\n+{\n+#ifdef CONFIG_EPOLL\n+\tif ((filp-\u003ef_mode \u0026 FMODE_READ) \u0026\u0026 filp-\u003ef_ep \u0026\u0026\n+\t    unlikely(!READ_ONCE(pipe-\u003eepoll_usage)))\n+\t\tWRITE_ONCE(pipe-\u003eepoll_usage, true);\n+#endif\n+}\n+\n+static bool pipe_get_epoll_usage(struct pipe_inode_info *pipe)\n+{\n+#ifdef CONFIG_EPOLL\n+\treturn pipe-\u003eepoll_usage;\n+#endif\n+\treturn false;\n+}\n+\n static ssize_t\n anon_pipe_read(struct kiocb *iocb, struct iov_iter *to)\n {\n@@ -689,7 +706,7 @@ anon_pipe_write(struct kiocb *iocb, struct iov_iter *from)\n \t * Epoll nonsensically wants a wakeup whether the pipe\n \t * was already empty or not.\n \t */\n-\tif (was_empty || pipe-\u003epoll_usage)\n+\tif (was_empty || pipe_get_epoll_usage(pipe))\n \t\twake_up_interruptible_sync_poll(\u0026pipe-\u003erd_wait, EPOLLIN | EPOLLRDNORM);\n \tkill_fasync(\u0026pipe-\u003efasync_readers, SIGIO, POLL_IN);\n \tif (wake_next_writer)\n@@ -761,9 +778,7 @@ pipe_poll(struct file *filp, poll_table *wait)\n \tunion pipe_index idx;\n \n \t/* Epoll has some historical nasty semantics, this enables them */\n-\tif (unlikely(!READ_ONCE(pipe-\u003epoll_usage)))\n-\t\tWRITE_ONCE(pipe-\u003epoll_usage, true);\n-\n+\tpipe_set_epoll_usage(filp, pipe);\n \t/*\n \t * Reading pipe state only -- no need for acquiring the semaphore.\n \t *\ndiff --git a/include/linux/pipe_fs_i.h b/include/linux/pipe_fs_i.h\nindex 7f6a92ac970478..d06da9bad3a8cc 100644\n--- a/include/linux/pipe_fs_i.h\n+++ b/include/linux/pipe_fs_i.h\n@@ -74,7 +74,7 @@ union pipe_index {\n  *\t@files: number of struct file referring this pipe (protected by -\u003ei_lock)\n  *\t@r_counter: reader counter\n  *\t@w_counter: writer counter\n- *\t@poll_usage: is this pipe used for epoll, which has crazy wakeups?\n+ *\t@epoll_usage: is this pipe used for epoll, which has crazy wakeups?\n  *\t@fasync_readers: reader side fasync\n  *\t@fasync_writers: writer side fasync\n  *\t@bufs: the circular array of pipe buffers\n@@ -95,7 +95,9 @@ struct pipe_inode_info {\n \tunsigned int files;\n \tunsigned int r_counter;\n \tunsigned int w_counter;\n-\tbool poll_usage;\n+#ifdef CONFIG_EPOLL\n+\tbool epoll_usage;\n+#endif\n #ifdef CONFIG_WATCH_QUEUE\n \tbool note_loss;\n #endif\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "EPOLL"
  ],
  "FocusSymbols": [
    "pipe_set_epoll_usage",
    "pipe_poll"
  ],
  "Reasoning": "The patch modifies the pipe polling logic to only set the epoll usage flag when actually used by epoll (checking filp-\u003ef_ep), rather than any poll usage. This changes the wakeup behavior in anon_pipe_write. This is a functional change to core kernel pipe/epoll interaction.",
  "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).

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.
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.
   Do not list too generic configs (we already have them enabled). Only list those that
   specifically cover the modified code. 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 067460c3946e60a228df053f61833ff43dafcf8c
Author: syz-cluster <triage@syzkaller.com>
Date:   Fri Jul 24 18:41:43 2026 +0000

    syz-cluster: applied patch under review

diff --git a/fs/pipe.c b/fs/pipe.c
index 429b0714ec5755..fa4e70d5f90d89 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -357,6 +357,23 @@ static inline unsigned int pipe_update_tail(struct pipe_inode_info *pipe,
 	return tail;
 }
 
+static void pipe_set_epoll_usage(struct file *filp, struct pipe_inode_info *pipe)
+{
+#ifdef CONFIG_EPOLL
+	if ((filp->f_mode & FMODE_READ) && filp->f_ep &&
+	    unlikely(!READ_ONCE(pipe->epoll_usage)))
+		WRITE_ONCE(pipe->epoll_usage, true);
+#endif
+}
+
+static bool pipe_get_epoll_usage(struct pipe_inode_info *pipe)
+{
+#ifdef CONFIG_EPOLL
+	return pipe->epoll_usage;
+#endif
+	return false;
+}
+
 static ssize_t
 anon_pipe_read(struct kiocb *iocb, struct iov_iter *to)
 {
@@ -689,7 +706,7 @@ anon_pipe_write(struct kiocb *iocb, struct iov_iter *from)
 	 * Epoll nonsensically wants a wakeup whether the pipe
 	 * was already empty or not.
 	 */
-	if (was_empty || pipe->poll_usage)
+	if (was_empty || pipe_get_epoll_usage(pipe))
 		wake_up_interruptible_sync_poll(&pipe->rd_wait, EPOLLIN | EPOLLRDNORM);
 	kill_fasync(&pipe->fasync_readers, SIGIO, POLL_IN);
 	if (wake_next_writer)
@@ -761,9 +778,7 @@ pipe_poll(struct file *filp, poll_table *wait)
 	union pipe_index idx;
 
 	/* Epoll has some historical nasty semantics, this enables them */
-	if (unlikely(!READ_ONCE(pipe->poll_usage)))
-		WRITE_ONCE(pipe->poll_usage, true);
-
+	pipe_set_epoll_usage(filp, pipe);
 	/*
 	 * Reading pipe state only -- no need for acquiring the semaphore.
 	 *
diff --git a/include/linux/pipe_fs_i.h b/include/linux/pipe_fs_i.h
index 7f6a92ac970478..d06da9bad3a8cc 100644
--- a/include/linux/pipe_fs_i.h
+++ b/include/linux/pipe_fs_i.h
@@ -74,7 +74,7 @@ union pipe_index {
  *	@files: number of struct file referring this pipe (protected by ->i_lock)
  *	@r_counter: reader counter
  *	@w_counter: writer counter
- *	@poll_usage: is this pipe used for epoll, which has crazy wakeups?
+ *	@epoll_usage: is this pipe used for epoll, which has crazy wakeups?
  *	@fasync_readers: reader side fasync
  *	@fasync_writers: writer side fasync
  *	@bufs: the circular array of pipe buffers
@@ -95,7 +95,9 @@ struct pipe_inode_info {
 	unsigned int files;
 	unsigned int r_counter;
 	unsigned int w_counter;
-	bool poll_usage;
+#ifdef CONFIG_EPOLL
+	bool epoll_usage;
+#endif
 #ifdef CONFIG_WATCH_QUEUE
 	bool note_loss;
 #endif

gemini-3.1-pro-preview

null

null

							input: 2628
							output: 30
							thoughts: 302
						

**Analyzing a Pipe Patch for Epoll Integration**

Okay, so I'm looking at this patch that seems to be touching the pipe implementation, specifically `fs/pipe.c` and `include/linux/pipe_fs_i.h`. The core change I'm seeing is the renaming of `poll_usage` to `epoll_usage` within the `struct pipe_inode_info`, and it looks like this is conditional on `CONFIG_EPOLL` being enabled. Smart, keeps the core functionality clean if epoll isn't in play.

This is followed up by the introduction of `pipe_set_epoll_usage` and `pipe_get_epoll_usage` functions. That makes sense, encapsulating the access to this new flag. Then, it calls `pipe_set_epoll_usage(filp, pipe)` in `pipe_poll` and `pipe_get_epoll_usage(pipe)` in `anon_pipe_write` in place of the now-renamed/conditional `pipe->poll_usage` check. Seems straightforward: update the usage flag when a file descriptor enters the epoll loop and read the usage flag when writing.

However, let's zoom in on `pipe_set_epoll_usage`:

```c
static void pipe_set_epoll_usage(struct file *filp, struct pipe_inode_info *pipe)
{
#ifdef CONFIG_EPOLL
	if ((filp->f_mode & FMODE_READ) && filp->f_ep &&
	    unlikely(!READ_ONCE(pipe->epoll_usage)))
		WRITE_ONCE(pipe->epoll_usage, true);
#endif
}
```

Wait a second. What's this `filp->f_ep`? I don't recall seeing that in `struct file`. I'm familiar with `f_mode`, but `f_ep`? That needs clarifying. Okay, I'm going to quickly grep the kernel source for that `f_ep` field within the definition of `struct file`. Let's see what that reveals about its role in this context. It's likely related to the epoll file descriptor, but I need to make sure.

{
  "Expression": "f_ep",
  "PathPrefix": "include/linux/fs.h"
}

{
  "Output": "include/linux/fs.h=1221=static inline int ra_has_index(struct file_ra_state *ra, pgoff_t index)\n--\ninclude/linux/fs.h-1228- * struct file - Represents a file\ninclude/linux/fs.h:1229: * @f_lock: Protects f_ep, f_flags. Must not be taken from IRQ context.\ninclude/linux/fs.h-1230- * @f_mode: FMODE_* flags often used in hotpaths\n--\ninclude/linux/fs.h-1247- * @f_sb_err: per sb writeback errors\ninclude/linux/fs.h:1248: * @f_ep: link of all epoll hooks for this file\ninclude/linux/fs.h-1249- * @f_task_work: task work entry point\n--\ninclude/linux/fs.h=1255=struct file {\n--\ninclude/linux/fs.h-1284-#ifdef CONFIG_EPOLL\ninclude/linux/fs.h:1285:\tstruct hlist_head\t\t*f_ep;\ninclude/linux/fs.h-1286-#endif\n"
}

gemini-3.1-pro-preview

null

null

							input: 3755
							output: 27
							thoughts: 216
						

**Analyzing the Pipe Epoll Wakeup Patch**

Okay, so I'm looking at this patch and immediately see that the `f_ep` function pointer is conditionally compiled; it's only available if `CONFIG_EPOLL` is defined. That's the baseline. The core of this patch seems to be making functional changes to how pipe wakeups interact with `epoll`, `poll`, and `select`.

Previously, `pipe->poll_usage` was unconditionally set to `true` within `pipe_poll`.  That meant *any* call to poll, select, or epoll on a pipe would trigger that flag, turning it on. Now, this patch refines the logic. It only sets `pipe->poll_usage` to `true` if `filp->f_ep` is actually non-NULL, indicating a genuine epoll hook, and only if the file's mode (`filp->f_mode`) includes `FMODE_READ`.

Essentially, this is a change to the pipe wakeup behavior, specifically impacting `epoll`, `poll`, and `select`. The key benefit is that this revised logic prevents unnecessary wakeups for `poll` and `select` on pipes, and also, importantly, for write-only `epoll` instances. That's a definite improvement.

Now, I need to check something quickly. I need to determine if `CONFIG_EPOLL` is generally enabled by default. If it is not, then I'll need to figure out where we enable it in the configuration system. I'll take a quick peek at `init/Kconfig` to confirm its default state.

{
  "Expression": "config EPOLL",
  "PathPrefix": "init/Kconfig"
}

{
  "Output": "init/Kconfig=1859=config FUTEX_ROBUST_UNLOCK\n--\ninit/Kconfig-1861-\ninit/Kconfig:1862:config EPOLL\ninit/Kconfig-1863-\tbool \"Enable eventpoll support\" if EXPERT\n"
}

gemini-3.1-pro-preview

null

null

							input: 4424
							output: 33
							thoughts: 130
						

**Analyzing Pipe-Related Functions**

Okay, so this feature is enabled by default, interesting. I need to get a handle on the key functions involved here. Let's see... I've identified `pipe_set_epoll_usage`, `pipe_get_epoll_usage`, `anon_pipe_write`, and `pipe_poll`.

Hmm, now that I look at it, `anon_pipe_write` and `pipe_poll` are clearly in the hot path. They're performance-critical. I wonder if there are any other key functions at play here, which might be less obvious.

Aha! Looking closer, `pipe_set_epoll_usage` and `pipe_get_epoll_usage` are either static inline or static functions located in `fs/pipe.c`. Right, I should take a deeper look at that file to see what else might be going on. It's time to dive into `fs/pipe.c`.

{
  "Expression": "pipe_set_epoll_usage",
  "PathPrefix": "fs/pipe.c"
}

{
  "Output": "fs/pipe.c=330=static inline unsigned int pipe_update_tail(struct pipe_inode_info *pipe,\n--\nfs/pipe.c-359-\nfs/pipe.c:360:static void pipe_set_epoll_usage(struct file *filp, struct pipe_inode_info *pipe)\nfs/pipe.c-361-{\n--\nfs/pipe.c=774=pipe_poll(struct file *filp, poll_table *wait)\n--\nfs/pipe.c-780-\t/* Epoll has some historical nasty semantics, this enables them */\nfs/pipe.c:781:\tpipe_set_epoll_usage(filp, pipe);\nfs/pipe.c-782-\t/*\n"
}

gemini-3.1-pro-preview

null

null

							input: 4995
							output: 30
							thoughts: 54
						

Okay, let's break this down.

**Analyzing Pipe Operations**

Right, so `pipe_poll` is the core function for checking the status of a pipe. That makes sense, the entry point for polling the pipe. I'm also thinking about `anon_pipe_write` which is the top level write function for anonymous pipes, so I get the big picture. Are there any other high level function calls I should be aware of, which are the main entry points? I'm going to quickly check `anon_pipe_read` to see if that's the read equivalent. Okay, good. That should do for now.

{
  "Expression": "anon_pipe_read",
  "PathPrefix": "fs/pipe.c"
}

{
  "Output": "fs/pipe.c=377=static ssize_t\nfs/pipe.c:378:anon_pipe_read(struct kiocb *iocb, struct iov_iter *to)\nfs/pipe.c-379-{\n--\nfs/pipe.c=516=fifo_pipe_read(struct kiocb *iocb, struct iov_iter *to)\nfs/pipe.c-517-{\nfs/pipe.c:518:\tint ret = anon_pipe_read(iocb, to);\nfs/pipe.c-519-\tif (ret \u003e 0)\n--\nfs/pipe.c=1370=static const struct file_operations pipeanon_fops = {\nfs/pipe.c-1371-\t.open\t\t= fifo_open,\nfs/pipe.c:1372:\t.read_iter\t= anon_pipe_read,\nfs/pipe.c-1373-\t.write_iter\t= anon_pipe_write,\n"
}

gemini-3.1-pro-preview

null

null

							input: 5474
							output: 113
							thoughts: 628
						

**My Analysis of the Patch for Syzkaller Targeting**

Okay, let's break this down. The patch focuses on modifying how pipes interact with `epoll`, specifically within `anon_pipe_write` and `pipe_poll`. My initial thought was to simply add these functions to `FocusSymbols`. However, I'm already thinking about hot-path issues; `anon_pipe_write` and `pipe_poll` are super common.

Let's dig deeper. I saw `pipe_set_epoll_usage`, and it's static. Initially, I dismissed it because it's static and not exported, but then I remember syzkaller can still fuzz static functions if they're in DWARF info. This could be promising. But the prompt mentions, "avoiding generic hot-path functions to prevent skewed test distributions." This means `anon_pipe_write` and `pipe_poll` are probably out.

So, `pipe_set_epoll_usage` is looking good now. I need to be sure; let's check if it's inlined. It isn't marked as `inline`, but it is quite small. Let's list `pipe_poll` and `pipe_set_epoll_usage`, for now.

Now, does this patch require a specific configuration? Yes, the changes are conditional on `CONFIG_EPOLL`. I need to ensure that is set. So, I need to add `EPOLL` to `EnableConfigs`.

Let's review the rationale. The patch modifies the condition for marking a pipe as epoll-used, affecting wakeups in `anon_pipe_write`. It introduces `pipe_set_epoll_usage` and `pipe_get_epoll_usage` and restricts epoll usage to actual epoll use (checking `filp->f_ep` instead of any poll use). It's a functional change related to pipe and epoll interaction. This definitely seems worth fuzzing.

I'm confident in:

*   `WorthFuzzing: true`
*   `FocusSymbols: pipe_set_epoll_usage`, `pipe_poll`
*   `EnableConfigs: EPOLL`

Finally, let me double-check. The `f_ep` flag is only available with `CONFIG_EPOLL` by looking at `include/linux/fs.h`. Also, the patch itself guards the `epoll_usage` field in `struct pipe_inode_info`.

Okay, I'm ready to call `set-results`.

{
  "EnableConfigs": [
    "EPOLL"
  ],
  "FocusSymbols": [
    "pipe_set_epoll_usage",
    "pipe_poll"
  ],
  "Reasoning": "The patch modifies the pipe polling logic to only set the epoll usage flag when actually used by epoll (checking filp-\u003ef_ep), rather than any poll usage. This changes the wakeup behavior in anon_pipe_write. This is a functional change to core kernel pipe/epoll interaction.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "EPOLL"
  ],
  "FocusSymbols": [
    "pipe_set_epoll_usage",
    "pipe_poll"
  ],
  "Reasoning": "The patch modifies the pipe polling logic to only set the epoll usage flag when actually used by epoll (checking filp-\u003ef_ep), rather than any poll usage. This changes the wakeup behavior in anon_pipe_write. This is a functional change to core kernel pipe/epoll interaction.",
  "WorthFuzzing": true
}