Re: [PATCH net-next v3 4/5] net/sched: sch_taprio: cap the number of schedule entries
flat view
From: netdev-bot+sashiko@kernel.org
Date: 2026-10-14 09:15:43
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider. Critical: 0 · High: 0 · Medium: 1 · Low: 0 If you believe none of the issues are legitimate, please reply to each issue of Medium severity or higher and explain why the AI is wrong. If any of them are legitimate and you plan to respin, please let patchwork know by including "pw-bot: cr" as a separate line at the end of your reply (one such reply per series is enough). - [Medium] sch_taprio: hardware capability regression for SJA1110 due to 1024 entry cap --
quoted hunk ↗ jump to hunk
diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c --- a/net/sched/sch_taprio.c +++ b/net/sched/sch_taprio.c@@ -49,6 +49,13 @@ static struct static_key_false taprio_have_working_mqprio; */ #define TAPRIO_PICOS_PER_BYTE_MIN 17 +/* Each entry is a separate 368-byte sched_entry and, in full offload, is + * also composed into a per-entry offload array. The u16 nla_len admits + * roughly 5460 minimal 12-byte entries, pinning ~2 MiB; 1024 matches the + * SJA1105 schedule-table capacity (SJA1110 provides 4096) and the act_gate cap. + */ +#define TAPRIO_ENTRIES_MAX 1024U + struct sched_entry { /* Durations between this GCL entry and the GCL entry where the * respective traffic class gate closes
[Severity: Medium] The commit message notes that the SJA1110 schedule table holds 4096 entries, but TAPRIO_ENTRIES_MAX is set to 1024. Before this patch, a user could install and offload a taprio schedule with anywhere from 1025 up to the SJA1110 hardware limit. With this patch, parse_sched_list() fails those same configurations with -E2BIG before the driver ever sees them. So a working full-offload setup on SJA1110 stops installing after an upgrade. The commit message calls this net-next hardening, but it is still a user-visible regression for that hardware. Why was 1024 chosen over 4096? Is it only to match the act_gate cap? The allocation concern in the changelog would still be well bounded at 4096. Drivers that offload already have to check the entry count against their own table size, so a software-side cap at the largest known hardware capacity seems sufficient. If 1024 is intentional, for example because schedules above roughly 900 entries cannot be dumped anyway, could the changelog say that explicitly? It should state that SJA1110 users with more than 1024 entries will be broken by this change. -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/QDISC-H19Z.v3.r0.20261012193813%40mojatatu.com