Re: [PATCH v2] net/sched: act_gate: Limit the max value for cycletime

[Edward Adam Davis]

On Tue, 25 Aug 2026 05:31:28 -0400, Jamal Hadi Salim <jhs@xxxxxxxxxxxx> wrote:
> On Tue, Aug 25, 2026 at 5:01 AM Edward Adam Davis <eadavis@xxxxxx> wrote:
> >
> > On Tue, 25 Aug 2026 04:25:04 -0400, Jamal Hadi Salim <jhs@xxxxxxxxxxxx> wrote:
> > > On Sun, Aug 23, 2026 at 12:07 AM Edward Adam Davis <eadavis@xxxxxx> wrote:
> > > >
> > > > If the user passes a cycletime value of 0xFFFFFFFFFFFFFFFFULL,
> > > > an overflow occurs during the assignment of cycle in gate_timer_func():
> > > >
> > > > cycle = p->tcfg_cycletime; // overflow, cycle = -1
> > > >
> > > > Since the local variable cycle is declared as ktime_t (i.e., s64),
> > > > the assignment overflows.
> > > >
> > >
> > > Review the sashiko feedback. At least two of those concerns look legit
> > > and need to be addressed:
> > > 1) complaint about timer disarm on replace 2) INT_MAX being too narrow
> > I haven't received any feedback regarding sashiko, and I didn't quite
> > understand the points made in item 1); could you please provide more
> > details?
> 
> You should always look at patchwork for reviews from the AIs - i just
> happened to have cycles and peeked and even my responses are best
> effort. Some maintainers forward AI reviews on a best-effort basis
> (Jakub forwarded you the v1 review), so you may end up getting radio
> silence if nobody has time. So, going forward, the first line of
> defense is to look at patchwork 24 hours + after you post your patch.
> Address those by sending a new version or rebut them on the list.
> > Regarding item 2), if INT_MAX is too narrow, do you have a suitable value
> > to recommend? S64_MAX?
> 
> Handwave: The safe bound is one that keeps base + cycletime <= KTIME_MAX.
> To be verbose per sashiko:
> cycletime is an unrestricted NLA_U64 consumed as ktime_t (s64). A 200
> s cycle time does not overflow any s64 arithmetic, but your v2 rejects
> it. tdc test a721
> (tools/testing/selftests/tc-testing/tc-tests/actions/gate.json) uses
> cycle-time 200000000000ns and expects success; your v2 breaks it.
> sch_taprio uses INT_MAX but its semantics/tests differ. S64_MAX is the
> actual overflow boundary (U64_MAX is what makes the s64 go negative);
> but even S64_MAX + a non-zero basetime wraps in base + (n+1)*cycle
Got it, thanks.

BR,
Edward