Re: [PATCH] net/sched: taprio: enforce minimum software scheduling interval

On Fri, 14 Aug 2026, Simon Horman wrote:
> Does this limit erroneously catch TXTIME_ASSIST offload configurations?

It does. Only pure software mode arms the per-entry hrtimer:
taprio_change() doesn't call taprio_start_sched() in txtime-assist
mode, and taprio_start_sched() returns early for full offload. So I
think the check wants to be

      if (!FULL_OFFLOAD_IS_ENABLED(q->flags) &&
          !TXTIME_ASSIST_IS_ENABLED(q->flags))

I gave that a spin on a patched kernel: a 2x50us txtime-assist
schedule on veth is still accepted, while the same 50us software
schedule is rejected.

On Fri, 14 Aug 2026, Hillf Danton wrote:
> Better if you specify why interval like 2us is ruled out.

The yardstick is the service cost of one expiry. On a release build I
see ~5.1M local timer interrupts in 5s on the owning CPU for a 700ns
single-entry schedule on veth, so the whole per-expiry service path is
around a microsecond; Uladzislau estimated ~10us per invocation on the
syzbot debug config earlier in the moderation thread. A 2us interval
still livelocks a debug build, and on a release build it pins a
permanent ~500k irqs/s on one CPU. 100us keeps margin above the
debug-config cost.

One more thing that came out of testing this: the floor only covers
half of the problem. A valid schedule that falls behind replays its
whole backlog one hrtimer expiry at a time. With a 4x200us schedule
and CLOCK_TAI stepped forward 72h (think ptp4l's first big step, or a
VM pause) I get an RCU stall with the owning CPU stuck in hrtimer
expiry processing, and no admission check can catch that; syzbot's
reports show the same stall with advance_sched() on the stack. A
bounded catch-up in advance_sched() fixes it. Conversely, catch-up
alone doesn't help the storm case: the 700ns schedule is still
admitted and sustains ~1M irqs/s.

I have both halves ready as a series - a bounded catch-up in
advance_sched() plus this patch with the exemption folded in - tested
by syzbot against both reproducer buckets on net.git dd057113ac7b,
with a tc-testing case. I plan to post it in a day, keeping your
Signed-off-by on this one, unless you'd prefer to respin it yourself.