From:   Vladimir Oltean <vladimir.oltean@nxp.com>
To:     netdev@vger.kernel.org
Cc:     "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Jamal Hadi Salim <jhs@mojatatu.com>,
        Cong Wang <xiyou.wangcong@gmail.com>,
        Jiri Pirko <jiri@resnulli.us>,
        Vinicius Costa Gomes <vinicius.gomes@intel.com>,
        Kurt Kanzenbach <kurt@linutronix.de>,
        Gerhard Engleder <gerhard@engleder-embedded.com>,
        linux-kernel@vger.kernel.org
Subject: [PATCH net-next 2/3] net/sched: taprio: don't allow dynamic max_sdu to go negative after stab adjustment
Date:   Thu, 16 Feb 2023 00:46:31 +0200
Message-Id: <20230215224632.2532685-3-vladimir.oltean@nxp.com>
In-Reply-To: <20230215224632.2532685-1-vladimir.oltean@nxp.com>
References: <20230215224632.2532685-1-vladimir.oltean@nxp.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?bvYTNHMyULvpfAAkC31qZrV0hWKX/7smfid03xcnzB/SjLuh7FPVWxIcQ88g?=
 =?us-ascii?Q?ELTymWBQGH/OKLuYMltrUpXSjD8Ukb3W1uiOK0JG6+rySsp7Wi12uxHG+Pvh?=
 =?us-ascii?Q?r/rm/kiEb3M1r4FokNrf0YZkcH4X3Gfgeu1/kRrguM9D0k9LmFaDRztHKJB4?=
 =?us-ascii?Q?yvl7sm/dP4RUmJGDrFSEv/8do7Cbyaxgr/JEUne2kw8Q4bm9ciRpRXD8ShSW?=
 =?us-ascii?Q?G8F2E8IuJpQgDUe0gGezHCvJ3GcTNfy0y8AXShEbhiiC/6Ma7NIySw1mPUFD?=
 =?us-ascii?Q?nn+2/K0YST9rCkCfjmCkkOnu/XzQDBE9IZtGUgfJe3umE/BBhZ0HkbZZfdcz?=
 =?us-ascii?Q?L0GPIUtSUfdG9QCcOFDc1aqna+ALq4hGFdCS3spj/ksonn/8QEBU9oyYculC?=
 =?us-ascii?Q?rFJ1Ta0e2PLt956Tw0jj3ShF5OnI0ZHZhy/nfBVY70U3DLLUEkvnFMvsb2NT?=
 =?us-ascii?Q?HzZyxG/S9v1jQI7qU6n0O5XlR25CembhAeTLLJMP0/NBcymSSNhf10qGZYYc?=
 =?us-ascii?Q?eQB5XvynRSyJQQIT48JuVTU4ZtQANYGJ3CFVLdAwDGO+A1UdS6Esz9iaBy+L?=
 =?us-ascii?Q?QXtGMWAw99hqEVey/u9LDAMyAsBZuzXi1wolMJsOChsnBP6IkVrC1DTCyzHQ?=
 =?us-ascii?Q?xXmVgNNawffYqockg1LaXBYzpFVGMJcScikM2QIR5Ay6clAhlC/pXRao9uTt?=
 =?us-ascii?Q?mQvPgYFst88/PzI1DeOvcbUosxwJZslM+kruGNKR4Vp3lFVIdltdh4b9senx?=
 =?us-ascii?Q?HTenyCxpgZdVtab56ZguJcfiuzl8n+AfeNuEZrnE7QWjnfxVDhE0tEGCqh8m?=
 =?us-ascii?Q?oPko51bJxTtH4Cq186MPpoza4P8HsDZrW5ozGqj04Bh98lEHJDPBZ1TvWEQ8?=
 =?us-ascii?Q?wbcS8IJYTxvce1h0P7sljWgvE19pQafk5A6QGH7AX7r1aUkExD1Q/vQmyYq4?=
 =?us-ascii?Q?1ZnEjIjgi6AMHZxbzXxMtAco78Dcrg2vQ/+NShxqUFLhgGzNfGSGn/oWhfpO?=
 =?us-ascii?Q?IkWbYIChUZpk1m3szshDzQdNFRmzdzKuS2qSXZS/ffd99SmlOlz4GL6cuvMa?=
 =?us-ascii?Q?HdTTRK/q5sObca95Zk/8+4AOYPNfk1BI86K6tzECKPtYVgApClecvNyFoe+3?=
 =?us-ascii?Q?cuaAGP9VM0w7/xmzM19fUZxGHEONUe6PqtopTSiIEv+7xrW0X3QVvJY7pAB9?=
 =?us-ascii?Q?f8EYOvxtrOsQwES9Nvb4g89vN/BSFYdzRLYOFReKDBcqTaA24Zkxzx/IByVJ?=
 =?us-ascii?Q?l8/DhmzKFBwo59ABTmUIFkQGxIc7eUid4Uw2+aq0zJWSup0KwS8APtOXTmXb?=
 =?us-ascii?Q?TU2rzMda9kWMCNgW5xbilHNqLNuo+2NRsEfQP+Z7Z5KNho0o8MldrN47xgSU?=
 =?us-ascii?Q?HLQ+xeeRyJbL1+BPCayiUFlR+IyhXoSVet8i7Vyl+2kj+ozrOIwckmCkzwrt?=
 =?us-ascii?Q?fjC2VQy+c5DgiXBgG9HpWJviiSRCiH5L7JKF4LR2HpPyhEneL4LF9xZ7By8q?=
 =?us-ascii?Q?C09ErE6tzn1iiy7z67CvrkUWXvwv+FU2UCuIQsz79bAQQOMqlgxEfUO49LaQ?=
 =?us-ascii?Q?Kc+TaZpDChvvmm8BRHiyRvSBdGdR0AtGk5xcGuVYlBVnRBISINhDdFa/Lsmc?=
 =?us-ascii?Q?XA=3D=3D?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 47dc1550-53b1-44d1-9319-08db0fa68699
X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Feb 2023 22:46:50.2131
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Ji0bvSbknheIjZZQSo7oJC9czJHoTp5RUVtTwmJKoP4v4tW+kqATIHs5vE8qzJYF5W2JJA5U+zay2Qi0m1A5Gw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR04MB8748
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

The overhead specified in the size table comes from the user. With small
time intervals (or gates always closed), the overhead can be larger than
the max interval for that traffic class, and their difference is
negative.

What we want to happen is for max_sdu_dynamic to have the smallest
non-zero value possible (1) which means that all packets on that traffic
class are dropped on enqueue. However, since max_sdu_dynamic is u32, a
negative is represented as a large value and oversized dropping never
happens.

Use max_t with int to force a truncation of max_frm_len to no smaller
than dev->hard_header_len + 1, which in turn makes max_sdu_dynamic no
smaller than 1.

Fixes: fed87cc6718a ("net/sched: taprio: automatically calculate queueMaxSDU based on TC gate durations")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 net/sched/sch_taprio.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
index 556e72ec0f38..53ba4d6b0218 100644
--- a/net/sched/sch_taprio.c
+++ b/net/sched/sch_taprio.c
@@ -279,8 +279,14 @@ static void taprio_update_queue_max_sdu(struct taprio_sched *q,
 			u32 max_frm_len;
 
 			max_frm_len = duration_to_length(q, sched->max_open_gate_duration[tc]);
-			if (stab)
+			/* Compensate for L1 overhead from size table,
+			 * but don't let the frame size go negative
+			 */
+			if (stab) {
 				max_frm_len -= stab->szopts.overhead;
+				max_frm_len = max_t(int, max_frm_len,
+						    dev->hard_header_len + 1);
+			}
 			max_sdu_dynamic = max_frm_len - dev->hard_header_len;
 		}
 
-- 
2.34.1