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

On Thu, 13 Aug 2026 02:15:49 +0000 (UTC) Uladzislau Zhauniarovich wrote:
> When configuring taprio with a very small schedule interval (e.g., 129 ns),
> the kernel validates the interval against the time it takes to transmit a
> minimum-sized Ethernet frame (60 bytes). On high-speed links, this minimum
> duration is extremely small (e.g., 48 ns at 10 Gbps). Since the requested
> interval is larger than this, the validation passes. Virtual devices like
> veth or bonding can defeat this link-speed minimum check because they
> report inflated link speeds (e.g., veth reports 10 Gbps, and bonding sums
> member speeds).
> 
> However, when hardware offload is not used, taprio falls back to software
> scheduling and arms an hrtimer. The hrtimer is programmed to fire at the
> configured interval. If this interval is too small, it cannot sustain the
> timer service cost of one advance_sched() invocation, which includes lock
> acquisition, budget recomputation, and TX softirq processing. As a result,
> the timer constantly falls behind, and the CPU is livelocked in hardirq
> context endlessly servicing the advance_sched() hrtimer. This starves the
> RCU grace-period kthreads, leading to an RCU stall panic:
> 
> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> rcu: 	1-...!: (1 GPs behind) idle=4854/0/0x1 softirq=136062/136068 fqs=0
> rcu: 	(detected by 0, t=10506 jiffies, g=161469, q=1866 ncpus=2)
> Sending NMI from CPU 0 to CPUs 1:
> NMI backtrace for cpu 1
> CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted
> Call Trace:
>  <IRQ>
>  lock_is_held include/linux/lockdep.h:249 [inline]
>  enqueue_hrtimer+0x79/0x2c0 kernel/time/hrtimer.c:1107
>  __run_hrtimer kernel/time/hrtimer.c:1946 [inline]
>  __hrtimer_run_queues+0x4ce/0xa10 kernel/time/hrtimer.c:1994
>  hrtimer_interrupt+0x448/0x910 kernel/time/hrtimer.c:2113
>  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1050 [inline]
>  __sysvec_apic_timer_interrupt+0x102/0x430 arch/x86/kernel/apic/apic.c:1067
>  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1061
>  [inline]
>  sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1061
>  </IRQ>
> 
> To fix this, enforce a hard absolute minimum interval of 100 microseconds

Better if you specify why interval like 2us is ruled out.

> (TAPRIO_MIN_SW_INTERVAL_NS) for software-based scheduling, which provides
> enough margin over the timer service cost. Fully offloaded schedules are
> unaffected since they do not rely on the CPU's hrtimer. Introduce a helper
> taprio_min_interval() to consolidate the minimum interval logic for both
> individual schedule entries and the overall cycle_time validation.