AI Trajectory

null

{
  "EnableConfigs": [
    "NET_SCH_TAPRIO"
  ],
  "FocusSymbols": [
    "fill_sched_entry",
    "parse_taprio_schedule",
    "taprio_min_interval"
  ],
  "Reasoning": "The patch modifies the validation logic for schedule entries in the taprio qdisc. It introduces a minimum interval for software scheduling to prevent CPU livelocks. This is a functional change in the traffic control subsystem that is reachable from userspace via netlink.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 8bcb3f4ea53ff63b3fa570cf9612e15117a17acd\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Wed Jul 22 20:24:18 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 45245157e00a69..2bf4cae164bc21 100644\n--- a/net/sched/sch_taprio.c\n+++ b/net/sched/sch_taprio.c\n@@ -49,6 +49,13 @@ static struct static_key_false taprio_have_working_mqprio;\n  */\n #define TAPRIO_PICOS_PER_BYTE_MIN 17\n \n+/* The software scheduler cannot sustain hrtimer intervals smaller than\n+ * this without livelocking the CPU. The value must exceed the cost of\n+ * one advance_sched() invocation (lock acquisition, budget recomputation,\n+ * TX softirq) with margin.\n+ */\n+#define TAPRIO_MIN_SW_INTERVAL_NS (100 * 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@@ -259,6 +266,16 @@ static int length_to_duration(struct taprio_sched *q, int len)\n \treturn div_u64(len * atomic64_read(\u0026q-\u003epicos_per_byte), PSEC_PER_NSEC);\n }\n \n+static int taprio_min_interval(struct taprio_sched *q)\n+{\n+\tint min_duration = length_to_duration(q, ETH_ZLEN);\n+\n+\tif (!FULL_OFFLOAD_IS_ENABLED(q-\u003eflags))\n+\t\tmin_duration = max_t(int, min_duration, TAPRIO_MIN_SW_INTERVAL_NS);\n+\n+\treturn min_duration;\n+}\n+\n static int duration_to_length(struct taprio_sched *q, u64 duration)\n {\n \treturn div_u64(duration * PSEC_PER_NSEC, atomic64_read(\u0026q-\u003epicos_per_byte));\n@@ -1038,7 +1055,7 @@ 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 = taprio_min_interval(q);\n \tu32 interval = 0;\n \n \tif (tb[TCA_TAPRIO_SCHED_ENTRY_CMD])\n@@ -1054,7 +1071,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. When software scheduling is used, the\n+\t * interval must also be at least the minimum hrtimer interval.\n \t */\n \tif (interval \u003c min_duration) {\n \t\tNL_SET_ERR_MSG(extack, \"Invalid interval for schedule entry\");\n@@ -1166,7 +1184,7 @@ 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 (s64)new-\u003enum_entries * taprio_min_interval(q)) {\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",
    "taprio_min_interval"
  ],
  "Reasoning": "The patch modifies the validation logic for schedule entries in the taprio qdisc. It introduces a minimum interval for software scheduling to prevent CPU livelocks. This is a functional change in the traffic control subsystem that is reachable from userspace via netlink.",
  "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 8bcb3f4ea53ff63b3fa570cf9612e15117a17acd
Author: syz-cluster <triage@syzkaller.com>
Date:   Wed Jul 22 20:24:18 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
index 45245157e00a69..2bf4cae164bc21 100644
--- a/net/sched/sch_taprio.c
+++ b/net/sched/sch_taprio.c
@@ -49,6 +49,13 @@ static struct static_key_false taprio_have_working_mqprio;
  */
 #define TAPRIO_PICOS_PER_BYTE_MIN 17
 
+/* The software scheduler cannot sustain hrtimer intervals smaller than
+ * this without livelocking the CPU. The value must exceed the cost of
+ * one advance_sched() invocation (lock acquisition, budget recomputation,
+ * TX softirq) with margin.
+ */
+#define TAPRIO_MIN_SW_INTERVAL_NS (100 * NSEC_PER_USEC)
+
 struct sched_entry {
 	/* Durations between this GCL entry and the GCL entry where the
 	 * respective traffic class gate closes
@@ -259,6 +266,16 @@ static int length_to_duration(struct taprio_sched *q, int len)
 	return div_u64(len * atomic64_read(&q->picos_per_byte), PSEC_PER_NSEC);
 }
 
+static int taprio_min_interval(struct taprio_sched *q)
+{
+	int min_duration = length_to_duration(q, ETH_ZLEN);
+
+	if (!FULL_OFFLOAD_IS_ENABLED(q->flags))
+		min_duration = max_t(int, min_duration, TAPRIO_MIN_SW_INTERVAL_NS);
+
+	return min_duration;
+}
+
 static int duration_to_length(struct taprio_sched *q, u64 duration)
 {
 	return div_u64(duration * PSEC_PER_NSEC, atomic64_read(&q->picos_per_byte));
@@ -1038,7 +1055,7 @@ 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 = taprio_min_interval(q);
 	u32 interval = 0;
 
 	if (tb[TCA_TAPRIO_SCHED_ENTRY_CMD])
@@ -1054,7 +1071,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. When software scheduling is used, the
+	 * interval must also be at least the minimum hrtimer interval.
 	 */
 	if (interval < min_duration) {
 		NL_SET_ERR_MSG(extack, "Invalid interval for schedule entry");
@@ -1166,7 +1184,7 @@ 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 < (s64)new->num_entries * taprio_min_interval(q)) {
 		NL_SET_ERR_MSG(extack, "'cycle_time' is too small");
 		return -EINVAL;
 	}

gemini-3.1-pro-preview

null

null

							input: 2634
							output: 30
							thoughts: 178
						

**Analyzing the Taprio Scheduler Patch**

Okay, so I've got this patch that's touching `net/sched/sch_taprio.c`. Seems like the core of the change revolves around this new `taprio_min_interval()` function. Interesting. It's computing the minimum interval for the Taprio scheduler, which is crucial for determining scheduling accuracy.

I see that it's defaulting to `TAPRIO_MIN_SW_INTERVAL_NS` – which, ah, that's 100 microseconds – when full offload isn't enabled. That makes sense, software-based scheduling needs a certain granularity. This impacts `fill_sched_entry` and `parse_taprio_schedule`, which is where the schedule entries get, well, filled and parsed, so I should definitely check how these functions work.

Now, I'm thinking about configuration. I know this file lives in the `tc` subsystem – traffic control – specifically the Taprio scheduler. So, I need to verify which configuration option enables it. My intuition says it’s likely `NET_SCH_TAPRIO`, but I always double-check. Time to grab `grepper` and confirm that.

{
  "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: 3198
							output: 35
							thoughts: 138
						

**Analyzing the TAPRIO Configuration Patch**

Okay, so the configuration in question revolves around `NET_SCH_TAPRIO`. I see this patch is focused on altering the functions `fill_sched_entry` and `parse_taprio_schedule`. These are critical, as they're the interface to user space through netlink, specifically when we're adding a TAPRIO qdisc with `tc qdisc add ... taprio`.

The core of the change seems functional, altering the validation logic for `interval` and `cycle_time`. This is where it gets interesting, preventing intervals below `TAPRIO_MIN_SW_INTERVAL_NS` in software scheduling mode. The goal is clear: prevent CPU livelock. That's a classic performance pitfall to avoid.

Time to delve into the code itself. I need to take a look at `net/sched/sch_taprio.c` and thoroughly examine the implementation of `fill_sched_entry` and `parse_taprio_schedule` to understand the exact mechanics of the validation change and ensure there are no unintended consequences. I'll pay close attention to the interaction of the new validation rules with the various scheduling modes.

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

{
  "Output": "net/sched/sch_taprio.c=1037=static const struct nla_policy taprio_policy[TCA_TAPRIO_ATTR_MAX + 1] = {\n--\nnet/sched/sch_taprio.c-1053-\nnet/sched/sch_taprio.c:1054:static int fill_sched_entry(struct taprio_sched *q, struct nlattr **tb,\nnet/sched/sch_taprio.c-1055-\t\t\t    struct sched_entry *entry,\n--\nnet/sched/sch_taprio.c=1087=static int parse_sched_entry(struct taprio_sched *q, struct nlattr *n,\n--\nnet/sched/sch_taprio.c-1102-\nnet/sched/sch_taprio.c:1103:\treturn fill_sched_entry(q, tb, entry, extack);\nnet/sched/sch_taprio.c-1104-}\n"
}

gemini-3.1-pro-preview

null

null

							input: 3872
							output: 115
							thoughts: 149
						

**My Analysis of the TAPRIO Qdisc Patch**

Okay, so I've been looking at this patch related to the TAPRIO qdisc. From what I can see, `fill_sched_entry` and `parse_taprio_schedule` are core components within the configuration path of the TAPRIO qdisc itself. I know for a fact these functions are both reachable and working correctly.

The patch itself is focusing on the validation of the schedule entries. The main point is a new minimum interval for software scheduling is being added. I understand the reasoning - it's a preventative measure against potential CPU livelocks, which makes complete sense in a performance-critical subsystem like traffic control. It’s important to note this is a functional change. Userspace will definitely interact with this through netlink.

I'd say this represents a change that will impact user configuration, and therefore, performance. Let's make sure our tests cover the relevant set-results.

{
  "EnableConfigs": [
    "NET_SCH_TAPRIO"
  ],
  "FocusSymbols": [
    "fill_sched_entry",
    "parse_taprio_schedule",
    "taprio_min_interval"
  ],
  "Reasoning": "The patch modifies the validation logic for schedule entries in the taprio qdisc. It introduces a minimum interval for software scheduling to prevent CPU livelocks. This is a functional change in the traffic control subsystem that is reachable from userspace via netlink.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "NET_SCH_TAPRIO"
  ],
  "FocusSymbols": [
    "fill_sched_entry",
    "parse_taprio_schedule",
    "taprio_min_interval"
  ],
  "Reasoning": "The patch modifies the validation logic for schedule entries in the taprio qdisc. It introduces a minimum interval for software scheduling to prevent CPU livelocks. This is a functional change in the traffic control subsystem that is reachable from userspace via netlink.",
  "WorthFuzzing": true
}