AI Trajectory

null

{
  "EnableConfigs": [
    "NET_SCH_TAPRIO"
  ],
  "FocusSymbols": [
    "fill_sched_entry",
    "parse_taprio_schedule"
  ],
  "Reasoning": "The patch introduces a minimum interval (TAPRIO_MIN_INTERVAL) for taprio schedule entries to prevent hrtimer interrupt storms. This is a functional change in the taprio network scheduler that modifies how schedule entries and cycle times are validated.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit b1806980d7212709f54f6906fb3f7af4dfa78f93\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Tue Jul 21 08:53:19 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c\nindex 299234a5f0fe60..d759a99e501fb0 100644\n--- a/net/sched/sch_taprio.c\n+++ b/net/sched/sch_taprio.c\n@@ -49,6 +49,9 @@ static struct static_key_false taprio_have_working_mqprio;\n  */\n #define TAPRIO_PICOS_PER_BYTE_MIN 17\n \n+/* Safe minimum interval to prevent hrtimer interrupt storms */\n+#define TAPRIO_MIN_INTERVAL NSEC_PER_USEC\n+\n struct sched_entry {\n \t/* Durations between this GCL entry and the GCL entry where the\n \t * respective traffic class gate closes\n@@ -1038,7 +1041,8 @@ static int fill_sched_entry(struct taprio_sched *q, struct nlattr **tb,\n \t\t\t    struct sched_entry *entry,\n \t\t\t    struct netlink_ext_ack *extack)\n {\n-\tint min_duration = length_to_duration(q, ETH_ZLEN);\n+\tint min_duration = max_t(int, length_to_duration(q, ETH_ZLEN),\n+\t\t\t\t TAPRIO_MIN_INTERVAL);\n \tu32 interval = 0;\n \n \tif (tb[TCA_TAPRIO_SCHED_ENTRY_CMD])\n@@ -1054,7 +1058,8 @@ static int fill_sched_entry(struct taprio_sched *q, struct nlattr **tb,\n \t\t\ttb[TCA_TAPRIO_SCHED_ENTRY_INTERVAL]);\n \n \t/* The interval should allow at least the minimum ethernet\n-\t * frame to go out.\n+\t * frame to go out, and should be large enough to prevent\n+\t * hrtimer interrupt storms.\n \t */\n \tif (interval \u003c min_duration) {\n \t\tNL_SET_ERR_MSG(extack, \"Invalid interval for schedule entry\");\n@@ -1166,7 +1171,9 @@ static int parse_taprio_schedule(struct taprio_sched *q, struct nlattr **tb,\n \t\tnew-\u003ecycle_time = cycle;\n \t}\n \n-\tif (new-\u003ecycle_time \u003c new-\u003enum_entries * length_to_duration(q, ETH_ZLEN)) {\n+\tif (new-\u003ecycle_time \u003c\n+\t    new-\u003enum_entries * max_t(int, length_to_duration(q, ETH_ZLEN),\n+\t\t\t\t     TAPRIO_MIN_INTERVAL)) {\n \t\tNL_SET_ERR_MSG(extack, \"'cycle_time' is too small\");\n \t\treturn -EINVAL;\n \t}\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "NET_SCH_TAPRIO"
  ],
  "FocusSymbols": [
    "fill_sched_entry",
    "parse_taprio_schedule"
  ],
  "Reasoning": "The patch introduces a minimum interval (TAPRIO_MIN_INTERVAL) for taprio schedule entries to prevent hrtimer interrupt storms. This is a functional change in the taprio network scheduler that modifies how schedule entries and cycle times are validated.",
  "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 b1806980d7212709f54f6906fb3f7af4dfa78f93
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Jul 21 08:53:19 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
index 299234a5f0fe60..d759a99e501fb0 100644
--- a/net/sched/sch_taprio.c
+++ b/net/sched/sch_taprio.c
@@ -49,6 +49,9 @@ static struct static_key_false taprio_have_working_mqprio;
  */
 #define TAPRIO_PICOS_PER_BYTE_MIN 17
 
+/* Safe minimum interval to prevent hrtimer interrupt storms */
+#define TAPRIO_MIN_INTERVAL NSEC_PER_USEC
+
 struct sched_entry {
 	/* Durations between this GCL entry and the GCL entry where the
 	 * respective traffic class gate closes
@@ -1038,7 +1041,8 @@ static int fill_sched_entry(struct taprio_sched *q, struct nlattr **tb,
 			    struct sched_entry *entry,
 			    struct netlink_ext_ack *extack)
 {
-	int min_duration = length_to_duration(q, ETH_ZLEN);
+	int min_duration = max_t(int, length_to_duration(q, ETH_ZLEN),
+				 TAPRIO_MIN_INTERVAL);
 	u32 interval = 0;
 
 	if (tb[TCA_TAPRIO_SCHED_ENTRY_CMD])
@@ -1054,7 +1058,8 @@ static int fill_sched_entry(struct taprio_sched *q, struct nlattr **tb,
 			tb[TCA_TAPRIO_SCHED_ENTRY_INTERVAL]);
 
 	/* The interval should allow at least the minimum ethernet
-	 * frame to go out.
+	 * frame to go out, and should be large enough to prevent
+	 * hrtimer interrupt storms.
 	 */
 	if (interval < min_duration) {
 		NL_SET_ERR_MSG(extack, "Invalid interval for schedule entry");
@@ -1166,7 +1171,9 @@ static int parse_taprio_schedule(struct taprio_sched *q, struct nlattr **tb,
 		new->cycle_time = cycle;
 	}
 
-	if (new->cycle_time < new->num_entries * length_to_duration(q, ETH_ZLEN)) {
+	if (new->cycle_time <
+	    new->num_entries * max_t(int, length_to_duration(q, ETH_ZLEN),
+				     TAPRIO_MIN_INTERVAL)) {
 		NL_SET_ERR_MSG(extack, "'cycle_time' is too small");
 		return -EINVAL;
 	}

gemini-3.1-pro-preview

null

null

							input: 2375
							output: 30
							thoughts: 312
						

**Analyzing a Taprio Patch**

Okay, so I'm looking at this patch for `net/sched/sch_taprio.c`. Seems straightforward enough, but these kinds of changes in a network scheduler always warrant a careful look. Essentially, they're introducing a minimum interval for Taprio schedule entries. The code defines `TAPRIO_MIN_INTERVAL` as `NSEC_PER_USEC`, which translates to 1 microsecond.

The patch then uses this minimum interval in `fill_sched_entry` and `parse_taprio_schedule`. The logic's pretty clear: it uses `max_t` to ensure that the calculated duration for a schedule entry is *at least* 1 microsecond. This is a classic move to avoid a potential hrtimer interrupt storm. That's a definite functional change - preventing those storms.

The obvious next step is fuzzing. Interrupt storms are a prime target for fuzzing, and making this change is intended to improve reliability under extreme conditions. I should put this on the fuzzing list. I need to make sure this doesn't introduce any regressions or unexpected behavior.

Now, to understand the context and how to fuzz it effectively, I need to know the config. Let me use `git grep` to find the config option that enables or controls this `net/sched/sch_taprio.c` functionality. Knowing the config will help me write test cases and tailor the fuzzing appropriately.

{
  "Expression": "sch_taprio.o",
  "PathPrefix": "net/sched/"
}

{
  "Output": "net/sched/Makefile=63=obj-$(CONFIG_NET_SCH_ETF)\t+= sch_etf.o\nnet/sched/Makefile:64:obj-$(CONFIG_NET_SCH_TAPRIO)\t+= sch_taprio.o\nnet/sched/Makefile-65-obj-$(CONFIG_NET_SCH_BPF)\t+= bpf_qdisc.o\n"
}

gemini-3.1-pro-preview

null

null

							input: 3126
							output: 31
							thoughts: 56
						

Okay, here's my take on those modifications.

**My Analysis of the TAPRIO Configuration Changes**

Right, so we're dealing with a specific configuration here: `NET_SCH_TAPRIO`. That immediately tells me we're looking at Traffic Aware Prioritized Scheduling – a fairly specialized QoS mechanism, typically used in time-sensitive networking (TSN) environments. The key functions being adjusted are `fill_sched_entry` and `parse_taprio_schedule`. Makes sense; `fill_sched_entry` would be responsible for populating the data structures that define a particular scheduled transmission (like the start time, duration, and priority of a frame), while `parse_taprio_schedule` is the function used to process the actual TAPRIO schedule configuration from the device tree or user space.

Okay, I need to add those functions to `FocusSymbols`. That's standard practice, right? This will ensure the build system can properly track dependencies and include them as necessary, especially if we're dealing with kernel modules or dynamic loading. Good, makes perfect sense.

But before I get too far down the rabbit hole, I should do a quick sweep of the configuration space to see if any other configurations are impacted by this change. It would be an oversight not to ensure that there aren't any other configs that may be related to this one. I am thinking, are there other dependencies, or conflicts? Better safe than sorry. I'm going to run a check, just to be sure.

{
  "Expression": "config NET_SCH_TAPRIO",
  "PathPrefix": "net/sched/"
}

{
  "Output": "net/sched/Kconfig=167=config NET_SCH_MQPRIO_LIB\n--\nnet/sched/Kconfig-171-\nnet/sched/Kconfig:172:config NET_SCH_TAPRIO\nnet/sched/Kconfig-173-\ttristate \"Time Aware Priority (taprio) Scheduler\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 3621
							output: 34
							thoughts: 23
						

Here's a summary of my thought process:

**Diving into the TAPRIO Dependencies**

Okay, so I need to understand the dependencies related to `NET_SCH_TAPRIO`. My immediate instinct is to check the `net/sched/Kconfig` file. That's the standard place to find configuration options and their relationships within the network scheduling (net/sched) subsystem of the kernel. This file is the key to understanding what other features, drivers, or modules need to be enabled or are incompatible with TAPRIO. I'll quickly look for the `NET_SCH_TAPRIO` entry within that file to see what it depends on, any conflicting options, and understand the general context within the scheduling ecosystem. This should give me a solid foundation for any further investigation or configuration changes I may need to make.

{
  "File": "net/sched/Kconfig",
  "FirstLine": 170,
  "LineCount": 20
}

{
  "Contents": " 170:\t\t  Common library for manipulating mqprio queue configurations.\n 171:\t\n 172:\tconfig NET_SCH_TAPRIO\n 173:\t\ttristate \"Time Aware Priority (taprio) Scheduler\"\n 174:\t\tselect NET_SCH_MQPRIO_LIB\n 175:\t\thelp\n 176:\t\t  Say Y here if you want to use the Time Aware Priority (taprio) packet\n 177:\t\t  scheduling algorithm.\n 178:\t\n 179:\t\t  See the top of \u003cfile:net/sched/sch_taprio.c\u003e for more details.\n 180:\t\n 181:\t\t  To compile this code as a module, choose M here: the\n 182:\t\t  module will be called sch_taprio.\n 183:\t\n 184:\tconfig NET_SCH_GRED\n 185:\t\ttristate \"Generic Random Early Detection (GRED)\"\n 186:\t\thelp\n 187:\t\t  Say Y here if you want to use the Generic Random Early Detection\n 188:\t\t  (GRED) packet scheduling algorithm for some of your network devices\n 189:\t\t  (see the top of \u003cfile:net/sched/sch_red.c\u003e for details and\n"
}

gemini-3.1-pro-preview

null

null

							input: 4183
							output: 104
							thoughts: 125
						

**Analyzing the Taprio Scheduler Modification**

Okay, so looking at this, there aren't any direct dependencies I need to worry about, other than enabling `NET_SCH_MQPRIO_LIB` as a prerequisite. My understanding is that `NET_SCH_TAPRIO` is the config option I'm interested in for enabling the Taprio scheduler itself.

The core of this patch seems to be about introducing a `TAPRIO_MIN_INTERVAL`. That immediately flags a potential issue – it's designed to mitigate hrtimer interrupt storms within the taprio scheduler. Essentially, they're changing how schedule entries and cycle times are validated. Interesting. I need to focus on how that logic affects things.

My primary areas of concern will be within the `fill_sched_entry` and `parse_taprio_schedule` functions, those will be my go-to symbols here. I need to understand exactly what they've changed and how the new minimum interval is being enforced during parsing and entry creation.

Given the nature of the change, specifically preventing potential denial-of-service, this is definitely worth fuzzing. I'll flag it as such and get to work on setting up some fuzzing campaigns.

{
  "EnableConfigs": [
    "NET_SCH_TAPRIO"
  ],
  "FocusSymbols": [
    "fill_sched_entry",
    "parse_taprio_schedule"
  ],
  "Reasoning": "The patch introduces a minimum interval (TAPRIO_MIN_INTERVAL) for taprio schedule entries to prevent hrtimer interrupt storms. This is a functional change in the taprio network scheduler that modifies how schedule entries and cycle times are validated.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "NET_SCH_TAPRIO"
  ],
  "FocusSymbols": [
    "fill_sched_entry",
    "parse_taprio_schedule"
  ],
  "Reasoning": "The patch introduces a minimum interval (TAPRIO_MIN_INTERVAL) for taprio schedule entries to prevent hrtimer interrupt storms. This is a functional change in the taprio network scheduler that modifies how schedule entries and cycle times are validated.",
  "WorthFuzzing": true
}