Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Vladimir Oltean <vladimir.oltean@nxp.com>
To:     netdev@vger.kernel.org
Cc:     Vinicius Costa Gomes <vinicius.gomes@intel.com>,
        Jamal Hadi Salim <jhs@mojatatu.com>,
        Cong Wang <xiyou.wangcong@gmail.com>,
        Jiri Pirko <jiri@resnulli.us>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Voon Weifeng <weifeng.voon@intel.com>,
        Vladimir Oltean <olteanv@gmail.com>,
        Kurt Kanzenbach <kurt@linutronix.de>,
        linux-kernel@vger.kernel.org
Subject: [PATCH net 2/3] net/sched: taprio: make qdisc_leaf() see the per-netdev-queue pfifo child qdiscs
Date:   Wed, 14 Sep 2022 17:34:38 +0300
Message-Id: <20220914143439.1544363-3-vladimir.oltean@nxp.com>
In-Reply-To: <20220914143439.1544363-1-vladimir.oltean@nxp.com>
References: <20220914143439.1544363-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?Fe8ILetIorOYp9WBZwc9IIdX4lt7TuuIJz9mJhjohMQQgMSWxqEiFgXTFnrH?=
 =?us-ascii?Q?2bSAuGP2UduGbIHdv0gVDuPO9ObMv9W/HmANlqzxhqdiK2UpIJz0j/ANARtA?=
 =?us-ascii?Q?yImmvKKUbSy0Xr9M+kdeh0uup0croRtx0az5sYkQpI56ebW3zupPW/FGNSHV?=
 =?us-ascii?Q?nn4BJs+KeZ499GlJeaA8gploFigmgNTYFNEz1Ijm78x73TqzxBQXM64PBEIV?=
 =?us-ascii?Q?90Ecb+F9zA7gmPl8ZCeJ828n9s7pvWhswKx5+UNl/KcrWP5mDHQkc2LczxEL?=
 =?us-ascii?Q?ACFPalqn2Jme7gEIfrpXvfYfQo2xTg9vR7TX6srLCiai+2xbiD29SHiW5eJF?=
 =?us-ascii?Q?yCfSTCWLbI4BcpUhV5RAQLQP/4RgJqaS1TXalNan39U7Ov6a4NZBlUmN3zaP?=
 =?us-ascii?Q?dY4oKW2hA0pFPCgPGmip5fUQTDQ8DWOL83hkmgzWrwhUepbAgIpE3bCaViF4?=
 =?us-ascii?Q?dzg6R7SwUPz2gcjl0dZerfiiQkUVOhdzDOT2xPDssjIOi5y5ITCF0BtM2Qky?=
 =?us-ascii?Q?wYKbOljde5uXasVfuFec9nKhV53yqQnSSqUBrqBNuXlaC5K88Fu9IrT0B/N2?=
 =?us-ascii?Q?Me3rGf3VIxjxhTqJDMy73mYxAMXN9XAC8GHGXXXEgk5DPFvKqo+ARW25kO2F?=
 =?us-ascii?Q?kG9//0E4ezmk8Mta1bKfJo4bV6X0/bVNPm4Ur6t8gRAE9oJt9cIB/VOQJ1Xm?=
 =?us-ascii?Q?R2cBfzWtz7x3U2qy8T4cgjoi8q+gXgD5xR2RBgXwghBD1f1FTeFWes5UZ79f?=
 =?us-ascii?Q?r1lsRHyvVbr29jLJHi1ohxB+Y/dM/DTPCEPLF26ZJSFKlCSOOBshnWMXys5a?=
 =?us-ascii?Q?vDoxG8L7bm0yfesVPG4u1+ppEMCKlje7kh6DCKn1amdrHDOYTbqsaLLb9Uun?=
 =?us-ascii?Q?cefz36/9d27UQ3G8D4ezda6dhz6fNhQ5aywskkP6ypK+CdBmeXTr9knoBrJH?=
 =?us-ascii?Q?akXq3E7ZWUpAWojOBuBpA/U/my8MW4BrdK2PiTAAhP2Nlfs8bcMVEou0fIKB?=
 =?us-ascii?Q?cL4dFUXMsPqN1TomKP/mI4gPQfi6Du/+6KI0v7uIoVqjHPCFw2tPFDEisc9n?=
 =?us-ascii?Q?GpXgg5zCRj/eL36hZL3mthYs7mXqhMYrADHTNxoajlcqIcvZ4XKpUH7TW+cw?=
 =?us-ascii?Q?miWfb9Wh8I1z5s5q6njGzsSTbDPMBpnADr6d5Kb9X9YDpb9WmFjfscSF+5xc?=
 =?us-ascii?Q?o1LJVQv7lJBsCU07hthAyU+44gjGqKCw0dT7zxgYj/EpXS8gmsEgvnPenUAt?=
 =?us-ascii?Q?GS/DqWpYnY2bU1J1XLX2OU8WADS3YjXlnd5f8dgignRAsbSKpTJ6glPNZCms?=
 =?us-ascii?Q?Ccc3uxMpLEcq324uTY8DEdIfo70/rf4j8vfNXLVdAiEsHKwN6WtaMLaQB+BR?=
 =?us-ascii?Q?zEzOuP33ip8MussjO425sfRNjsZi5JeJL/sQwoOK3jeRSJ4POWUcOvpnqBCh?=
 =?us-ascii?Q?bPkEaHqvBPdIOJVg/3BCNdHZRnl0omBFYyKBmU6uxVvuGjD8Xm7nN9q3Uds3?=
 =?us-ascii?Q?biy1ZAd/nmxklqI79BUbQEoEFQgGacGdd1eeGGkPa9LL0eeFLrXbbCl8owPc?=
 =?us-ascii?Q?Vb5GX90/eyoses90KdueewXk/0KUlzntcLGxWQeGc5YpNcQeSx4ekFdsGK5S?=
 =?us-ascii?Q?9w=3D=3D?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5356dda9-1239-44b7-1a3a-08da965e4dcb
X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2022 14:35:00.4938
 (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: eNtPFGWV6C1x4mkzARSZ96wBGfcRfYCszoksf5h8rngDui9O90Gelvycg3zVc7qHMseoXlwiW8FVohYSdnag2w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR04MB6777
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

taprio can only operate as root qdisc, and to that end, there exists the
following check in taprio_init(), just as in mqprio:

	if (sch->parent != TC_H_ROOT)
		return -EOPNOTSUPP;

And indeed, when we try to attach taprio to an mqprio child, it fails as
expected:

$ tc qdisc add dev swp0 root handle 1: mqprio num_tc 8 \
	map 0 1 2 3 4 5 6 7 \
	queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0
$ tc qdisc replace dev swp0 parent 1:2 taprio num_tc 8 \
	map 0 1 2 3 4 5 6 7 \
	queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \
	base-time 0 sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \
	flags 0x0 clockid CLOCK_TAI
Error: sch_taprio: Can only be attached as root qdisc.

(extack message added by me)

But when we try to attach a taprio child to a taprio root qdisc,
surprisingly it doesn't fail:

$ tc qdisc replace dev swp0 root handle 1: taprio num_tc 8 \
	map 0 1 2 3 4 5 6 7 queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \
	base-time 0 sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \
	flags 0x0 clockid CLOCK_TAI
$ tc qdisc replace dev swp0 parent 1:2 taprio num_tc 8 \
	map 0 1 2 3 4 5 6 7 \
	queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \
	base-time 0 sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \
	flags 0x0 clockid CLOCK_TAI

This is because tc_modify_qdisc() behaves differently when mqprio is
root, vs when taprio is root.

In the mqprio case, it finds the parent qdisc through
p = qdisc_lookup(dev, TC_H_MAJ(clid)), and then the child qdisc through
q = qdisc_leaf(p, clid). This leaf qdisc q has handle 0, so it is
ignored according to the comment right below ("It may be default qdisc,
ignore it"). As a result, tc_modify_qdisc() goes through the
qdisc_create() code path, and this gives taprio_init() a chance to check
for sch_parent != TC_H_ROOT and error out.

Whereas in the taprio case, the returned q = qdisc_leaf(p, clid) is
different. It is not the default qdisc created for each netdev queue
(both taprio and mqprio call qdisc_create_dflt() and keep them in
a private q->qdiscs[], or priv->qdiscs[], respectively). Instead, taprio
makes qdisc_leaf() return the _root_ qdisc, aka itself.

When taprio does that, tc_modify_qdisc() goes through the qdisc_change()
code path, because the qdisc layer never finds out about the child qdisc
of the root. And through the ->change() ops, taprio has no reason to
check whether its parent is root or not, just through ->init(), which is
not called.

The problem is the taprio_leaf() implementation. Even though code wise,
it does the exact same thing as mqprio_leaf() which it is copied from,
it works with different input data. This is because mqprio does not
attach itself (the root) to each device TX queue, but one of the default
qdiscs from its private array.

In fact, since commit 13511704f8d7 ("net: taprio offload: enforce qdisc
to netdev queue mapping"), taprio does this too, but just for the full
offload case. So if we tried to attach a taprio child to a fully
offloaded taprio root qdisc, it would properly fail too; just not to a
software root taprio.

To fix the problem, stop looking at the Qdisc that's attached to the TX
queue, and instead, always return the default qdiscs that we've
allocated (and to which we privately enqueue and dequeue, in software
scheduling mode).

Since Qdisc_class_ops :: leaf  is only called from tc_modify_qdisc(),
the risk of unforeseen side effects introduced by this change is
minimal.

Fixes: 5a781ccbd19e ("tc: Add support for configuring the taprio scheduler")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 net/sched/sch_taprio.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
index a3b4f92a9937..5bffc37022e0 100644
--- a/net/sched/sch_taprio.c
+++ b/net/sched/sch_taprio.c
@@ -1949,12 +1949,14 @@ static int taprio_dump(struct Qdisc *sch, struct sk_buff *skb)
 
 static struct Qdisc *taprio_leaf(struct Qdisc *sch, unsigned long cl)
 {
-	struct netdev_queue *dev_queue = taprio_queue_get(sch, cl);
+	struct taprio_sched *q = qdisc_priv(sch);
+	struct net_device *dev = qdisc_dev(sch);
+	unsigned int ntx = cl - 1;
 
-	if (!dev_queue)
+	if (ntx >= dev->num_tx_queues)
 		return NULL;
 
-	return dev_queue->qdisc_sleeping;
+	return q->qdiscs[ntx];
 }
 
 static unsigned long taprio_find(struct Qdisc *sch, u32 classid)
-- 
2.34.1