From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Krystian Kaniewski <krystianmkaniewski@gmail.com>,
Jamal Hadi Salim <jhs@mojatatu.com>,
Jiri Pirko <jiri@resnulli.us>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: Simon Horman <horms@kernel.org>,
Vladimir Oltean <vladimir.oltean@nxp.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v2 1/2] net/sched: taprio: reject software schedules that overflow their timestamps
Date: Mon, 12 Oct 2026 15:36:43 -0700 [thread overview]
Message-ID: <87mrsilf5w.fsf@intel.com> (raw)
In-Reply-To: <20261009123309.284193-2-krystianmkaniewski@gmail.com>
Krystian Kaniewski <krystianmkaniewski@gmail.com> writes:
> taprio takes base-time as an unbounded signed 64-bit value. A base time
> in the future is used as the schedule start unchanged, and
> setup_first_end_time() then adds the cycle time, the first interval and
> the gate durations of the first entry to it. With a start close to
> KTIME_MAX these sums overflow, and the software schedule starts with end
> and gate close times that lie far in the past.
>
> If this is the first schedule, the qdisc timer is armed for its future
> start. With an operational schedule running, taprio_start_sched() keeps
> the earlier operational expiry instead. A large cycle-time-extension
> can then trigger an early handover to the pending admin schedule.
> advance_sched() uses the invalid entry end as the next expiry and can
> keep restarting inside the same timer interrupt.
>
> Before a software schedule is initialized and published, check that the
> computed start is not negative and leaves room for every timestamp
> initialized from it, and reject the schedule with -ERANGE otherwise. Full
> offload and txtime-assist do not use the software timer and are not
> affected. Schedules with a reasonable base time behave as before.
>
> Fixes: 5a781ccbd19e ("tc: Add support for configuring the taprio scheduler")
> Assisted-by: Codex:gpt-6.1-sol
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Krystian Kaniewski <krystianmkaniewski@gmail.com>
> ---
Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
--
Vinicius
next prev parent reply other threads:[~2026-10-12 22:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-09 12:33 [PATCH net v2 0/2] net/sched: taprio: fix RCU stall from replayed schedule entries Krystian Kaniewski
2026-10-09 12:33 ` [PATCH net v2 1/2] net/sched: taprio: reject software schedules that overflow their timestamps Krystian Kaniewski
2026-10-12 22:36 ` Vinicius Costa Gomes [this message]
2026-10-09 12:33 ` [PATCH net v2 2/2] net/sched: taprio: do not replay missed entries in advance_sched() Krystian Kaniewski
2026-10-12 22:53 ` Vinicius Costa Gomes
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=87mrsilf5w.fsf@intel.com \
--to=vinicius.gomes@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=krystianmkaniewski@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.