From: Krystian Kaniewski <krystianmkaniewski@gmail.com>
To: Vinicius Costa Gomes <vinicius.gomes@intel.com>,
Jamal Hadi Salim <jhs@mojatatu.com>,
Jiri Pirko <jiri@resnulli.us>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: Simon Horman <horms@kernel.org>,
Vladimir Oltean <vladimir.oltean@nxp.com>,
Vedang Patel <vedang.patel@intel.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
syzbot+e044a9b6370ed8ca9737@syzkaller.appspotmail.com
Subject: [PATCH net v3 3/3] net/sched: taprio: do not replay missed entries in advance_sched()
Date: Wed, 4 Nov 2026 15:17:13 +0100 [thread overview]
Message-ID: <20261104141713.355958-4-krystianmkaniewski@gmail.com> (raw)
In-Reply-To: <20261104141713.355958-1-krystianmkaniewski@gmail.com>
advance_sched() advances the software schedule by one entry per hrtimer
expiry and rearms the timer at the nominal end of that entry, without
reading the clock. When that time has already passed, the hrtimer core
runs the callback again inside the same interrupt, once for every missed
entry.
syzbot hits this with a single 127 ns entry on a veth device.
fill_sched_entry() only rejects intervals below the transmission time of
a minimum sized frame, which is 48 ns at the 10 Gb/s reported by veth,
so 127 ns is accepted. One expiry takes longer than 127 ns, so the
backlog grows instead of shrinking, the CPU stays in the timer interrupt
and RCU reports a stall. Lateness from a forward step of CLOCK_REALTIME
or CLOCK_TAI, from resume with CLOCK_BOOTTIME, or from a long time with
interrupts disabled leads to the same replay with any interval.
Record when the schedule starts and the period after which it repeats,
which is the cycle time, or the sum of the intervals when the entries
end before the cycle does. Whenever the entry that advance_sched() is
about to start has already ended, find the entry in progress from these
two values and continue from there. This selects the entry and the end
time that the replay would have reached, so a schedule that keeps up
with its timer behaves as before. The same check covers the first entry
after taprio_change() resets the current entry of a running schedule,
and the first entry of an admin schedule that takes over late.
advance_sched() now evaluates should_change_schedules() once on the
caught up end time instead of once per missed entry. This relies on
should_change_schedules() saturating the cycle_time_extension sum, which
makes the test monotonic in end_time. One check after catching up is
therefore equivalent to the repeated checks.
This bounds the work done per expiry. It does not limit how often the
timer fires. Unless the clock is stepped backward between the hrtimer
core reading it and the callback reading it, the timer is rearmed after
the current time and the CPU leaves the timer interrupt between
expiries. On the high-resolution hard interrupt path, a schedule whose
intervals are shorter than one expiry is then held back by the hang
detection in hrtimer_interrupt().
Fixes: 5a781ccbd19e ("tc: Add support for configuring the taprio scheduler")
Reported-by: syzbot+e044a9b6370ed8ca9737@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=e044a9b6370ed8ca9737
Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Signed-off-by: Krystian Kaniewski <krystianmkaniewski@gmail.com>
---
v3:
- move cycle-time-extension overflow handling to patch 2 (Vinicius)
- return the cycle end from taprio_entry_at() and update
cycle_end_time in advance_sched() (Vinicius)
- add Acked-by from Vinicius
- drop the obsolete Assisted-by trailers
- rebase onto current net/main
v2: https://lore.kernel.org/all/20261009123309.284193-3-krystianmkaniewski@gmail.com/
- taprio_entry_at(): do not use the list iterator after the loop.
Return the entry through a separate pointer that is set inside the
loop, and say in the comment why it is always set (Jakub)
- wrap the lines longer than 80 columns, with a local variable for the
number of elapsed periods in taprio_entry_at()
v1: https://lore.kernel.org/all/20261006113335.241564-3-krystianmkaniewski@gmail.com/
net/sched/sch_taprio.c | 127 ++++++++++++++++++++++++++++++++++-------
1 file changed, 106 insertions(+), 21 deletions(-)
diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
index e4c937cf74c10f..5a1dca9d5e9dec 100644
--- a/net/sched/sch_taprio.c
+++ b/net/sched/sch_taprio.c
@@ -90,6 +90,13 @@ struct sched_gate_list {
s64 cycle_time;
s64 cycle_time_extension;
s64 base_time;
+ /* The software schedule starts at start_time and repeats every period,
+ * which is the cycle time, or the sum of the intervals when the
+ * entries end before the cycle does, because advance_sched() then
+ * starts the list again right after the last entry.
+ */
+ ktime_t start_time;
+ s64 period;
};
struct taprio_sched {
@@ -942,16 +949,61 @@ static bool should_change_schedules(const struct sched_gate_list *admin,
return false;
}
+/* Return the entry of @sched which is in progress at @now, the one that
+ * advance_sched() reaches by moving one entry per expiry from the start of
+ * the schedule. Set @start and @end to the times at which it started and
+ * ends, and @cycle_end to the end of the cycle which contains it.
+ */
+static struct sched_entry *
+taprio_entry_at(const struct sched_gate_list *sched, ktime_t now,
+ ktime_t *start, ktime_t *end, ktime_t *cycle_end)
+{
+ struct sched_entry *entry, *found = NULL;
+ ktime_t cycle_start = sched->start_time;
+ s64 offset, entry_end = 0, elapsed = 0;
+
+ if (ktime_after(now, cycle_start)) {
+ s64 periods = div64_s64(ktime_sub(now, cycle_start),
+ sched->period);
+
+ cycle_start = ktime_add_ns(cycle_start,
+ periods * sched->period);
+ }
+ offset = ktime_sub(now, cycle_start);
+
+ /* The offset is less than one period, so an entry which ends after
+ * @now is found at the latest at the entry which reaches the end of
+ * the cycle, or at the last entry. A schedule has at least one entry,
+ * so the loop always sets found.
+ */
+ list_for_each_entry(entry, &sched->entries, list) {
+ entry_end = min_t(s64, elapsed + entry->interval,
+ sched->cycle_time);
+ if (offset < entry_end ||
+ list_is_last(&entry->list, &sched->entries)) {
+ found = entry;
+ break;
+ }
+ elapsed = entry_end;
+ }
+
+ *start = ktime_add_ns(cycle_start, elapsed);
+ *end = ktime_add_ns(cycle_start, entry_end);
+ *cycle_end = ktime_add_ns(cycle_start, sched->cycle_time);
+
+ return found;
+}
+
static enum hrtimer_restart advance_sched(struct hrtimer *timer)
{
struct taprio_sched *q = container_of(timer, struct taprio_sched,
advance_timer);
struct net_device *dev = qdisc_dev(q->root);
+ ktime_t cycle_end, end_time, start, now;
struct sched_gate_list *oper, *admin;
int num_tc = netdev_get_num_tc(dev);
struct sched_entry *entry, *next;
struct Qdisc *sch = q->root;
- ktime_t end_time;
int tc;
spin_lock(&q->current_entry_lock);
@@ -965,6 +1017,15 @@ static enum hrtimer_restart advance_sched(struct hrtimer *timer)
if (!oper)
switch_schedules(q, &admin, &oper);
+ /* The entry selected below can be over already, after a clock step,
+ * a long time with interrupts disabled, or because the intervals are
+ * shorter than one expiry takes. Moving on by one entry and arming the
+ * timer in the past would run this function again for every missed
+ * entry without leaving the timer interrupt. Take the entry which is in
+ * progress now instead, so that the timer is always armed after now.
+ */
+ now = taprio_get_time(q);
+
/* This can happen in two cases: 1. this is the very first run
* of this function (i.e. we weren't running any schedule
* previously); 2. The previous schedule just ended. The first
@@ -975,27 +1036,31 @@ static enum hrtimer_restart advance_sched(struct hrtimer *timer)
next = list_first_entry(&oper->entries, struct sched_entry,
list);
end_time = next->end_time;
- goto first_run;
- }
-
- if (should_restart_cycle(oper, entry)) {
- next = list_first_entry(&oper->entries, struct sched_entry,
- list);
- oper->cycle_end_time = ktime_add_ns(oper->cycle_end_time,
- oper->cycle_time);
+ if (likely(ktime_after(end_time, now)))
+ goto first_run;
+ /* Also after taprio_change() while the schedule runs */
+ next = taprio_entry_at(oper, now, &start, &end_time,
+ &cycle_end);
+ oper->cycle_end_time = cycle_end;
} else {
- next = list_next_entry(entry, list);
- }
-
- end_time = ktime_add_ns(entry->end_time, next->interval);
- end_time = min_t(ktime_t, end_time, oper->cycle_end_time);
+ if (should_restart_cycle(oper, entry)) {
+ next = list_first_entry(&oper->entries,
+ struct sched_entry, list);
+ oper->cycle_end_time =
+ ktime_add_ns(oper->cycle_end_time,
+ oper->cycle_time);
+ } else {
+ next = list_next_entry(entry, list);
+ }
- for (tc = 0; tc < num_tc; tc++) {
- if (next->gate_duration[tc] == oper->cycle_time)
- next->gate_close_time[tc] = KTIME_MAX;
- else
- next->gate_close_time[tc] = ktime_add_ns(entry->end_time,
- next->gate_duration[tc]);
+ start = entry->end_time;
+ end_time = ktime_add_ns(start, next->interval);
+ end_time = min_t(ktime_t, end_time, oper->cycle_end_time);
+ if (unlikely(!ktime_after(end_time, now))) {
+ next = taprio_entry_at(oper, now, &start, &end_time,
+ &cycle_end);
+ oper->cycle_end_time = cycle_end;
+ }
}
if (should_change_schedules(admin, oper, end_time)) {
@@ -1005,8 +1070,22 @@ static enum hrtimer_restart advance_sched(struct hrtimer *timer)
*/
next = list_first_entry(&oper->entries, struct sched_entry, list);
end_time = next->end_time;
+ if (likely(ktime_after(end_time, now)))
+ goto set_budgets;
+ next = taprio_entry_at(oper, now, &start, &end_time,
+ &cycle_end);
+ oper->cycle_end_time = cycle_end;
+ }
+
+ for (tc = 0; tc < num_tc; tc++) {
+ if (next->gate_duration[tc] == oper->cycle_time)
+ next->gate_close_time[tc] = KTIME_MAX;
+ else
+ next->gate_close_time[tc] =
+ ktime_add_ns(start, next->gate_duration[tc]);
}
+set_budgets:
next->end_time = end_time;
taprio_set_budgets(q, oper, next);
@@ -1319,7 +1398,8 @@ static void setup_first_end_time(struct taprio_sched *q,
{
struct net_device *dev = qdisc_dev(q->root);
int num_tc = netdev_get_num_tc(dev);
- struct sched_entry *first;
+ struct sched_entry *first, *entry;
+ s64 intervals = 0;
ktime_t cycle;
int tc;
@@ -1331,6 +1411,11 @@ static void setup_first_end_time(struct taprio_sched *q,
/* FIXME: find a better place to do this */
sched->cycle_end_time = ktime_add_ns(base, cycle);
+ list_for_each_entry(entry, &sched->entries, list)
+ intervals += entry->interval;
+ sched->start_time = base;
+ sched->period = min_t(s64, intervals, cycle);
+
first->end_time = ktime_add_ns(base, first->interval);
taprio_set_budgets(q, sched, first);
--
2.53.0
prev parent reply other threads:[~2026-11-04 14:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 14:17 [PATCH net v3 0/3] net/sched: taprio: fix RCU stall from replayed schedule entries Krystian Kaniewski
2026-11-04 14:17 ` [PATCH net v3 1/3] net/sched: taprio: reject software schedules that overflow their timestamps Krystian Kaniewski
2026-11-04 14:17 ` [PATCH net v3 2/3] net/sched: taprio: prevent cycle time extension overflow Krystian Kaniewski
2026-11-04 14:17 ` Krystian Kaniewski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261104141713.355958-4-krystianmkaniewski@gmail.com \
--to=krystianmkaniewski@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=syzbot+e044a9b6370ed8ca9737@syzkaller.appspotmail.com \
--cc=vedang.patel@intel.com \
--cc=vinicius.gomes@intel.com \
--cc=vladimir.oltean@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®