From patchwork Mon Aug 23 21:22:55 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 501732 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-18.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, MSGID_FROM_MTA_HEADER, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2778C4338F for ; Mon, 23 Aug 2021 21:23:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9A169613A8 for ; Mon, 23 Aug 2021 21:23:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232819AbhHWVYC (ORCPT ); Mon, 23 Aug 2021 17:24:02 -0400 Received: from mail-eopbgr80085.outbound.protection.outlook.com ([40.107.8.85]:59364 "EHLO EUR04-VI1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S232503AbhHWVX7 (ORCPT ); Mon, 23 Aug 2021 17:23:59 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a59RRfBQC9Mge9h0wm8SEeOEfUxO6Hed0lqz+ZrKLpxnfkQ/Fhq6eFAOwq4BFPqovvUbY1/vl2MNuhLIRfcJdYdi6y+MReyRmntY33SrKsgRBWBKTPcQ65OJsf57XKtWcg6r9OyDswbLmCthtLyFkPWgrPnX9VTr0iboHl/HKkMsfvan3X0phf4nCeqV0R5+S6PeshG+PZIEHeRm8ivHF2h5lvmfPLIC/NZpB2qF1wUS0aXBceCDq9mSliqAGSQ1Ne62mnAfdflGC3xO6BApiFZAdteqj2lK4+/mZLG6YOqm4H36xLEiwhKWCZ8jXbchAwMpg6hm0+gp+dC/UWeC9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lS08ksLDTATGQViWBzuBerZpUIvmHgME3NCskVLaIdg=; b=cUiGXkKYRFI+TXlggAH6cVV1lyFYImu97CFCXqb/73GypSxEJuRPH7/pDXctk0BpYBeXQy1PV1BipiadAHdboEuD8fhukjxoqWibFDP/nKnJ1fYt+zenA8G3mbK1YSJ8OZ0L0gKYEoUcNpdkbqItFMLeoP5nCRQ2PlDCzVT9E4PHfQBJpOeWtXhWD/KZgYujA+RNRfMjsF/gLeKJ32vEYbvIDUF9n1I/HtVEcrECgGYK72A+wUr40deLvpNA5uf/7otlOjKmnBQGLtl8O+FcHfMb40Ujcm0vfNqJxpqzNYN6tjAwC43CX14TlQav1FN5nf2f22Q8/NFw4MiL3ZSykg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lS08ksLDTATGQViWBzuBerZpUIvmHgME3NCskVLaIdg=; b=PIwMy57HkiS8wDwKh3c+Z8WGeSVjtd3mZkb1wJ1jOUK4C+SvIUf5yxvj3BQLx/ANxmI3gIFjvgis+rNbPvQdEqdRK1pwMwF1MnNSVmxQL5UmLOzeZ7N96lZpHwjkkkdzMdsUEI8zvp4Y22Yl7eiUASzybuL9P6oH6zt3InZ041c= Authentication-Results: vger.kernel.org; dkim=none (message not signed) header.d=none; vger.kernel.org; dmarc=none action=none header.from=nxp.com; Received: from VI1PR04MB5136.eurprd04.prod.outlook.com (2603:10a6:803:55::19) by VI1PR04MB4221.eurprd04.prod.outlook.com (2603:10a6:803:3e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Mon, 23 Aug 2021 21:23:14 +0000 Received: from VI1PR04MB5136.eurprd04.prod.outlook.com ([fe80::109:1995:3e6b:5bd0]) by VI1PR04MB5136.eurprd04.prod.outlook.com ([fe80::109:1995:3e6b:5bd0%2]) with mapi id 15.20.4436.025; Mon, 23 Aug 2021 21:23:14 +0000 From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Florian Fainelli , Andrew Lunn , Vivien Didelot , Vladimir Oltean , Tobias Waldekranz , Kurt Kanzenbach , =?utf-8?q?Alvin_=C5=A0ipraga?= Subject: [PATCH v2 net-next 1/4] net: dsa: don't call switchdev_bridge_port_unoffload for unoffloaded bridge ports Date: Tue, 24 Aug 2021 00:22:55 +0300 Message-Id: <20210823212258.3190699-2-vladimir.oltean@nxp.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210823212258.3190699-1-vladimir.oltean@nxp.com> References: <20210823212258.3190699-1-vladimir.oltean@nxp.com> X-ClientProxiedBy: AM3PR05CA0150.eurprd05.prod.outlook.com (2603:10a6:207:3::28) To VI1PR04MB5136.eurprd04.prod.outlook.com (2603:10a6:803:55::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost.localdomain (188.25.144.60) by AM3PR05CA0150.eurprd05.prod.outlook.com (2603:10a6:207:3::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.18 via Frontend Transport; Mon, 23 Aug 2021 21:23:13 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c5fe2bcd-f8ef-4d46-aa32-08d9667c3748 X-MS-TrafficTypeDiagnostic: VI1PR04MB4221: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:3968; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NCgjZTxE35h/f/qmGDLym4gigTnx4giE9nbOeKAr6Q33Ktas9rsrpogQ6Pczix5n7hPiJOlDuIKOsKMrM6r+Rh+ikVaey1wVZpO95FVvYcYUxnmUoKQPQuy55EmccU+jGe6phtOMJS+WynGcbN+VRNpe5/gnieuQ2KmyZRTZwUXw0OgwQgVJCx6alMREWJOvr2QXGnTozM2CkcXHtuSER9855pVwF5lUon5iRHTsglxQNUMCmBo6EzjC+lQ+F8WLPK3TsMwciATI9nV09HN5innhTBZ2UsVWHki+CmPVLvnIwRDOplFAcgrRfgTEHqfGiw9W+/CW+o58d3wVquKYXJvClV/UNB6Xa4dlMldQHcF1MqOPjot3Frpro7RaAZEACZJ5MORf3P/tSgEd9x534A0DP9We7K6FcpEIKSdKG0WsaUvpT6dOCoPcnCFxsBTGctEzuWEgmlaIeBm9QP56JnUQteVsScwvUOJ/xWkfYdzB+cMw2V4csAvzPToKpHxCIHuS0vH9+u4lCYeQr5p70YiA0dbVbK9pA/s3bMEVrLh8f3VyWPNa9a2WGBU6tbwOjWPgoypNyhGu1NPgwlLMZ0Uagw93w5fAo98LNl0S8YOa8j99tUGQo+J0k/0reYBzS0j0PrQraoyBL2cdUWDpHDwLFIefiudbHiMQcdx28Iw7cm9jrI7eWOjwUg5vL+D9SuB4yvkhUxIdT8V4ooG9Zg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5136.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(346002)(39850400004)(366004)(396003)(83380400001)(66476007)(66556008)(6506007)(26005)(4326008)(8676002)(66946007)(8936002)(6512007)(186003)(6486002)(86362001)(6666004)(38350700002)(6916009)(38100700002)(52116002)(5660300002)(316002)(44832011)(36756003)(54906003)(1076003)(2616005)(2906002)(478600001)(956004); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: SHrja/h1kzhrFiERkXUQlu+OOcDGzu+GOlQCY458GzM6fFMD6K3LxdUWSTocMuZ/lrLM7Hf69uy/Tj6IIrO2ObBLHB8ofVJsH04Ib8tFZ+j2TajKDy9HOP4T+6RFAzQSQLzf7G+ON19hecGJJfzxWSzsEHxbiWwuTrqkYFZilckwqY5QbOLk9MPbN4Uuifj8SR1b0hqYEcwl/bBuhgCkEd1nlPJh+ab+gIPjPb8neCQsBozt989vd3aO1TxxcOpUAkg6NhGnzBLp3tF+CflVio5r7mDavb5H0Bupo+VFfv2ZrcwBVin83N5Ibd1oBAIavuuYwsw6sr6uBuN6utviFkJujm/ImsntK27PwmQnHfPZ3UxXG7MiakQk8OoOJZdsbvUDskjaCmhgPtIPGeJtbg4fLCR541kuKuvLZServI699y+8Uelfv/ukDEYUWsYsle+euE2Bg9I1/wZhRS8IY1OCaraTCeZFoGAJBtpkkB4oBADbsYcsbQ4FWfL9VcZ2lhVzC2r/X8M8NDbHQjtYR3haqZv3SKN+giH+fn5Ayy92rdTJXXIWNmp/OgFGxieq3PzIyMSB64CyxVVreDkmyTsNLETqW0uwoQnSLBjmm2EeijJvNw9PERunHAM4yFGmJkMJxaFwX7R0aaae6KD2vUZ1WDGvacPqvYEnI7VmoL4uTubREiSEpMdRLoEDtUq6I8f+ISw0w0szfPFSq1d8z8TuUVBziNfL9SIPTxv7wJKcRltJRdkAarN2lzMWKy0Fneo0yz5bly9I2v7WA13WzxP9tdsEAHsZTdvInW/CKwbW2MpffIYDiyCaQT4ZlvO1nzi8bxLlUNua4NdTancLYPX+bo2rE05MyaQbO2Rm2Cmn+DHJsAw8FW8RCitwKXPQLjrYTc0HQtPKKnmHA+FN7plMCu+Ow8GjuABWoOhY3wdW8MkXQxVVOh/Xqclm6xaf7v8a1D0teP40EdRX3s99SZj7Zno6QOmy2Rpi6seNjnmKP0Mr9loBhr4y8CwUqUGlzb4Aby5xHmcPL1l3/lnIWv+GUztBkV2//peMRsTDpC/0R3fVQBVUAXUi5JGr6iWjJf1+YlA2FnIiE25fCwDr2ndRdla8C74SErtf/tYLtz6hsbbkUS2WJJGSk1ewBitVvRf5o0Lui+uKWxXN2atdwUE/LxzAAnKRsfJBMtYh2bT8fwyuUWbeySQ75r67PdYxi9WS0nCAU9kWKOepIYaSaCfbcvZczjkxakGOJFZbIXOAZwFiDeEI0crBajdV3AXIUUvxOzmUl54DC0bov7nMRGUQlWP7YoLF4YVtDf9BdHDHCr0FAn5i+g7/Wa6HXGbR X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: c5fe2bcd-f8ef-4d46-aa32-08d9667c3748 X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Aug 2021 21:23:14.1141 (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: NkQAgSG9WqfcuqU/xtl+EomIQR/pnTRTA69nk1iyvf2SYmlatDtbI4U9yaR6pVYF8ZMQolVxyBJJ8dy56rHVsg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB4221 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org For ports that have a NULL dp->bridge_dev, dsa_port_to_bridge_port() also returns NULL as expected. Issue #1 is that we are performing a NULL pointer dereference on brport_dev. Issue #2 is that these are ports on which switchdev_bridge_port_offload has not been called, so we should not call switchdev_bridge_port_unoffload on them either. Both issues are addressed by checking against a NULL brport_dev in dsa_port_pre_bridge_leave and exiting early. Fixes: 2f5dc00f7a3e ("net: bridge: switchdev: let drivers inform which bridge ports are offloaded") Signed-off-by: Vladimir Oltean --- v1->v2: Patch is new net/dsa/port.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/dsa/port.c b/net/dsa/port.c index 4fbe81ffb1ce..3b775d7adee2 100644 --- a/net/dsa/port.c +++ b/net/dsa/port.c @@ -373,6 +373,10 @@ void dsa_port_pre_bridge_leave(struct dsa_port *dp, struct net_device *br) { struct net_device *brport_dev = dsa_port_to_bridge_port(dp); + /* Don't try to unoffload something that is not offloaded */ + if (!brport_dev) + return; + switchdev_bridge_port_unoffload(brport_dev, dp, &dsa_slave_switchdev_notifier, &dsa_slave_switchdev_blocking_notifier); From patchwork Mon Aug 23 21:22:56 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 501731 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-18.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, MSGID_FROM_MTA_HEADER, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1ED50C432BE for ; Mon, 23 Aug 2021 21:23:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0683E613A8 for ; Mon, 23 Aug 2021 21:23:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232963AbhHWVYO (ORCPT ); Mon, 23 Aug 2021 17:24:14 -0400 Received: from mail-eopbgr30042.outbound.protection.outlook.com ([40.107.3.42]:5229 "EHLO EUR03-AM5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S232724AbhHWVYA (ORCPT ); Mon, 23 Aug 2021 17:24:00 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HeZGnL68QPSSEjCz1ajgJOCNGOQfXENVgwyqUwWGRPn67ST9p87+YeZKOsfCdIllDtPPmsKI0UOzCQnyR8WfIC6PtgztvNojjTooVT8WEQOf452NuRcT6L9Qj5TDLrgvhvZTZdGlu7mAAWz4rnYj/05woCH1txwb5DWbGcAUaRn5tBX9W0NLRotdK5oltcOcR5qIvpSTCIJvJaw7+dWA+d2i/sKVkf+F9aHu4IS/jiy1mxBZZdZTF5PmRmFIL4Ay+raqw6w6QiflpUj+WSnlno/NG80LmhqViuNe92/fFqNmxQarfD+anmns/YJtwh561rcecOsR6+bTfEEP/al0qQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3jV3mPb8PPAsAc846U6PNc4Qha/nVyXRJKB+MO1YCBQ=; b=LppSwtnkRcJD2xXBM+5rC6GmpKLs7R9qb7oh3j4EQl910Fdn5ATjIKGiOcRW6qcEB2ui9CDaXooqvKvnSUaTg0Phq9xymbPRVjWmAEhC/DtaobhaBxM3eI/5Ekj9VrnXIs94/ncFuT98LpD67q631D3w1eEa3REGNBcmfeh1dsJObjKTooYmZgxOh+69zJ7Z6XEqIFZtUkmsS9U1ZLLwiNEYCgm4zYFpvWU0UNFT2piQuujxxaOiu6y1wwbmsXxBYOBv9C+iAtwtC0I896NvEkcamAkOXBLEldtE/mbUI5JXIHIFYhkkZBrYHgL9XTz1Djbnq1dACGbUr/BMCjVoXQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3jV3mPb8PPAsAc846U6PNc4Qha/nVyXRJKB+MO1YCBQ=; b=XGh0uCRKgpoGTnwu2/geHWupgdgrfdXvX8vgurso5svMrwa6kcNQ7nm41LfR49986vWLatWLDk776ttfcCu4UATYGEMkuHmvoU222E1wqKYluMZ4TEnXPdxEaHhoxJSPq+w2LsDTSHa3yynNrhiOpMAKupVWjcJQrkhhBs2zu04= Authentication-Results: vger.kernel.org; dkim=none (message not signed) header.d=none; vger.kernel.org; dmarc=none action=none header.from=nxp.com; Received: from VI1PR04MB5136.eurprd04.prod.outlook.com (2603:10a6:803:55::19) by VI1PR0401MB2685.eurprd04.prod.outlook.com (2603:10a6:800:58::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Mon, 23 Aug 2021 21:23:15 +0000 Received: from VI1PR04MB5136.eurprd04.prod.outlook.com ([fe80::109:1995:3e6b:5bd0]) by VI1PR04MB5136.eurprd04.prod.outlook.com ([fe80::109:1995:3e6b:5bd0%2]) with mapi id 15.20.4436.025; Mon, 23 Aug 2021 21:23:15 +0000 From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Florian Fainelli , Andrew Lunn , Vivien Didelot , Vladimir Oltean , Tobias Waldekranz , Kurt Kanzenbach , =?utf-8?q?Alvin_=C5=A0ipraga?= Subject: [PATCH v2 net-next 2/4] net: dsa: properly fall back to software bridging Date: Tue, 24 Aug 2021 00:22:56 +0300 Message-Id: <20210823212258.3190699-3-vladimir.oltean@nxp.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210823212258.3190699-1-vladimir.oltean@nxp.com> References: <20210823212258.3190699-1-vladimir.oltean@nxp.com> X-ClientProxiedBy: AM3PR05CA0150.eurprd05.prod.outlook.com (2603:10a6:207:3::28) To VI1PR04MB5136.eurprd04.prod.outlook.com (2603:10a6:803:55::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost.localdomain (188.25.144.60) by AM3PR05CA0150.eurprd05.prod.outlook.com (2603:10a6:207:3::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.18 via Frontend Transport; Mon, 23 Aug 2021 21:23:14 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ffc078a3-070c-4472-32aa-08d9667c37e6 X-MS-TrafficTypeDiagnostic: VI1PR0401MB2685: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:4714; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Lal147Ysg8OR7a4Q6QawQDEwhmZkjPytwZkG9PGhMATvMTeDmI5IfRawFUoavNwrmrYzAbCzQGHXoKwUbATAWrezO6/soK4nzTJo6OVN/JPgKd4X5CtZ2wz6jJ7PyUIZECMCkOsjZSqhhQ0W0YUsn5w01G38Twv2c3rUrlgwkj3xfl2O+7tnybkgHQ58a91Yq1XBj1zDzEORrrTK8hO+YPAFK+iP4qO5MNjGh194s0t/cYePR1vpaLK2CLg3NJD8fE2z7kjDD0IBRc4ym4QD7+r4LmEhuomfySdkmNpoqSu2f+rC18PZOzM7Rjv/sWNZFOXl3ENX/PPm8wd42kevbJkYTI0rXQFxDoofSMjqfUv3eo6FpnupvTBi10O2vi6EveKGE1nQANJmPuoxhR1Er6+9pn9BDITD81IGjgnOGY5Yc+5rQ4Rw5VRC6MD2/bWpQSMX1JIMc9olv2aE9dJolZQ9BfrLAMXrslHnuaAjJMkJc3t0sTh0dOAgtUNTMe8/ToKQAXKvBxKwXQkzy8MK7FiKIDgnGh9eT+EXWo7W4tlEpqUFsqx8R16TdNMejK13Wi/vaRNClEZxKaZsRD3atZaoY9UG7PispAg0GjnVdx1sMZP1fKeRhHZVuTzlFgan+UCa07ddxGxKRkovmjo0+M6KjYBf+DLWzibcW++WMP3w/z2G1pDvI0xaaN+sAOvaW8RhGmB7YuW7iggPzqz04g== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5136.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(376002)(366004)(346002)(396003)(136003)(86362001)(66476007)(66946007)(66556008)(316002)(6916009)(54906003)(478600001)(83380400001)(66574015)(38100700002)(2906002)(38350700002)(186003)(36756003)(5660300002)(1076003)(6512007)(8936002)(6506007)(2616005)(956004)(6666004)(4326008)(44832011)(52116002)(6486002)(26005)(8676002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?q?udYIKM74tiHpz2IzJFZgwUu1i?= =?utf-8?q?88TOEgzFkQHndxP2x+WnAoRwrwsich7ltwSNw8luCNXM/4ZWbcDcxKoL?= =?utf-8?q?xhsUvr8XYysKVAABzTcEZCSc0MN912x4Oc72xtaWbfyghXt4PMFYvpX3?= =?utf-8?q?ji8lN71oe4IZY8SYWzS7xOd4oP3I6e8q2jq/gvPCebEpZPJoBvN7GRrD?= =?utf-8?q?q1kKh7OikN+vo2MA2UjVtgsejVfbcAiq5vLtWQnsjQ6Htu1W3oQYfRHM?= =?utf-8?q?NntwWc8Vqgmi6T6IhDQ0m5kumteYd4p2Ggr/12XnyMy5YKy1H6SG1dyF?= =?utf-8?q?eVtkVc2AJ9IFtQvTOg8/IuzMupSNeZ90j/zamTlJ9ooBE+0qUeNQvqXV?= =?utf-8?q?dmdE14pQ2cwQpCtlFMJY0pwTvz16HFUIMD8nJjx73+/Elsr/so+aOSmR?= =?utf-8?q?3zRx2jQQaTHxO5Qw3bcG2xISadUHp7uJWtrmWitOyyb8/oMm0Gl7rGJg?= =?utf-8?q?7JQE1RMjEBeKPKag8cPWObkiNLc6U/gVibCUdy+ENOn1M4YHruiF3oNc?= =?utf-8?q?dfAGKgxnhG5/5ghSvdcbYgsBrqBuhLZ/VngYy+uEEwgKXyHYy9TzKWyg?= =?utf-8?q?SpEXcnPIakX24UO7Uu/LmPbIvOeEFMKdR0fxobw7VJNlfYL5O7sl4Gwe?= =?utf-8?q?U+B5zaa50BoxdgOGSPS/mCB8qBVcnUqUbjR+QTWrexMI5LmiE+gJGrSG?= =?utf-8?q?Y4CAhZ3Ilq0vB0EcYlYGvUa+3k6ThbipIqj2sreQ+Qp0sdYENa/teG7s?= =?utf-8?q?DC2zUbpn9otmQwsu6/yOLOVXhsN0CRJUkrox6cI+a4eAnhwfNnesbt3F?= =?utf-8?q?wsKK84Khflc+0mirvQRo3x3MqdJzoa+JaIwGvgi0S82M4AayAQJIeDZE?= =?utf-8?q?4lGaJM/IVSc8IfieOPSkiA01QYWJ0j+22+NffSdeuodikTtNHpHf7h0G?= =?utf-8?q?M99sXbBLPDkIaT600mmWJxexa+UvpR8QbOZLUidmTuAJiXftifnwYvnU?= =?utf-8?q?/VJ1IQ2nG26+Yo4zDFGNXD+iZqDwcWbhsyQUtnC0XFvFP3XX3KpZrcrb?= =?utf-8?q?sGpeTRNedDPGjrf6+IpFYTzDqf3/jcAUK1Y151PEVHlBEr4gJNtLhIOj?= =?utf-8?q?ASWmy35OEFeKWg4K6gW6j4SA8SCWhlEM92ubdNYnDVH9AIl/XCsvu2jD?= =?utf-8?q?wHfdQSMuB6WKl1DpYxNioXgaZgra7eNZbJ2kXfPLIowFj5P68xh3ZU5N?= =?utf-8?q?q2Tw9EpaO5qm0AY8U0wfu8qVNxcZZxWs82Ll5lIzyTWvBOJFz3u6dhal?= =?utf-8?q?qRy+LUGj805Fq0rSH9/DTFG0uT6KBjRrqmSuVjM2vBpx1ckRpVL/6AZW?= =?utf-8?q?/E6no2Lqb7H/MYv4yuhzmBaAvYCAlHY?= X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: ffc078a3-070c-4472-32aa-08d9667c37e6 X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Aug 2021 21:23:15.1185 (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: oRSQYdTIjJp/zKjnG6R4AEzSXjmsGUWSg1jCny6YKn1K+Rg6u1GX+E6DK1MfPS24X5rXM10laHr08RlbJ2MM+A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2685 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org If the driver does not implement .port_bridge_{join,leave}, then we must fall back to standalone operation on that port, and trigger the error path of dsa_port_bridge_join. This sets dp->bridge_dev = NULL. In turn, having a non-NULL dp->bridge_dev when there is no offloading support makes the following things go wrong: - dsa_default_offload_fwd_mark make the wrong decision in setting skb->offload_fwd_mark. It should set skb->offload_fwd_mark = 0 for ports that don't offload the bridge, which should instruct the bridge to forward in software. But this does not happen, dp->bridge_dev is incorrectly set to point to the bridge, so the bridge is told that packets have been forwarded in hardware, which they haven't. - switchdev objects (MDBs, VLANs) should not be offloaded by ports that don't offload the bridge. Standalone ports should behave as packet-in, packet-out and the bridge should not be able to manipulate the pvid of the port, or tag stripping on egress, or ingress filtering. This should already work fine because dsa_slave_port_obj_add has: case SWITCHDEV_OBJ_ID_PORT_VLAN: if (!dsa_port_offloads_bridge_port(dp, obj->orig_dev)) return -EOPNOTSUPP; err = dsa_slave_vlan_add(dev, obj, extack); but since dsa_port_offloads_bridge_port works based on dp->bridge_dev, this is again sabotaging us. All the above work in case the port has an unoffloaded LAG interface, so this is well exercised code, we should apply it for plain unoffloaded bridge ports too. Reported-by: Alvin Šipraga Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli --- v1->v2: made a correction in the commit message about what's wrong: "dp->bridge_dev is non-NULL" rather than "dp->bridge_dev is NULL". net/dsa/slave.c | 5 +++++ net/dsa/switch.c | 6 ++++-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/net/dsa/slave.c b/net/dsa/slave.c index eb9d9e53c536..f785d24fcf23 100644 --- a/net/dsa/slave.c +++ b/net/dsa/slave.c @@ -2009,6 +2009,11 @@ static int dsa_slave_changeupper(struct net_device *dev, err = dsa_port_bridge_join(dp, info->upper_dev, extack); if (!err) dsa_bridge_mtu_normalization(dp); + if (err == -EOPNOTSUPP) { + NL_SET_ERR_MSG_MOD(extack, + "Offloading not supported"); + err = 0; + } err = notifier_from_errno(err); } else { dsa_port_bridge_leave(dp, info->upper_dev); diff --git a/net/dsa/switch.c b/net/dsa/switch.c index fd1a1c6bf9cf..dd042fd7f800 100644 --- a/net/dsa/switch.c +++ b/net/dsa/switch.c @@ -92,8 +92,10 @@ static int dsa_switch_bridge_join(struct dsa_switch *ds, struct dsa_switch_tree *dst = ds->dst; int err; - if (dst->index == info->tree_index && ds->index == info->sw_index && - ds->ops->port_bridge_join) { + if (dst->index == info->tree_index && ds->index == info->sw_index) { + if (!ds->ops->port_bridge_join) + return -EOPNOTSUPP; + err = ds->ops->port_bridge_join(ds, info->port, info->br); if (err) return err; From patchwork Mon Aug 23 21:22:57 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 501730 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-18.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, MSGID_FROM_MTA_HEADER, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB499C4320E for ; Mon, 23 Aug 2021 21:23:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B18BC613AD for ; Mon, 23 Aug 2021 21:23:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233002AbhHWVYR (ORCPT ); Mon, 23 Aug 2021 17:24:17 -0400 Received: from mail-eopbgr30042.outbound.protection.outlook.com ([40.107.3.42]:5229 "EHLO EUR03-AM5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S232710AbhHWVYC (ORCPT ); Mon, 23 Aug 2021 17:24:02 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EISrQn2smrs/9G8s1BzJJaaV+BRBfD7nXTFoKFdCgj/bmNGHdqlxohNLJeGJ1yupJRwZ37eWu2NxVWEgtL2SmrRYVMEvEJQS/1D/I/2C4lReMW5w8jnjIkCtvLFeG2SQsnAPCiXHDElqUI+IoY7ALOgKXBLJrtCaMFFK73SXTN1l0jDPyuU2ZXiovLMIfvueLpJvDGNbzjl5ESTI8yFZVfx6pxsu8qYMv1VuCohee1+kid8kc0CfujcjcaUdVJSPJnvhZf/2GoPqHAySAF110d7tkdIYiIKHBhz1+3ojZjbGwYUgaRG22ENWwl82fmriSF/5mJn2aOtL2HFtPhG85g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5DCzFl+wsIOkdp1E7x0r6M7ukSr4/Zdk7L146xJ6ZIA=; b=VcyX57uzeK/giZG39tcadMlfMg70UaI6p6sPWs23tU5xF2hBFl1F0yliXL7FcUah1+zXHDwoebAydHh5zDAasxBRYXHiIPLTqTmo8qMkCvnfDXSBLQLik9YjdK2GtvAGezD7jUw0Ket2ErKrnjxG9A8Jkwi7eCnGSRVfFOtNPQobS+hL5PqGqU2G8/7i6dGzxtazLaWR8oOEEriv/0ovI8I9lbPMYoazqZnY+NIB6cSUNgzkq1Za+NzOFoXnqAi7yE/MQy5Ff9P0NbmLMPkXAq7XeMlzwAjAmtJdbWxHTXrt01m8lr+VUdtDhCWHW96PeLuIPYm/QQXBCPE+IKY52w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5DCzFl+wsIOkdp1E7x0r6M7ukSr4/Zdk7L146xJ6ZIA=; b=m+vzD4FyVzfYr0+qyg3oikhl8LDtIgCeKkTdi3GIBf1JW/EBURAKaTzPgs7RAxW0SD1fKmW/l5GWVTiY4jqccqfnZmJq/zidRT6WEDs1pGr3kMNHAjK9VsuxY/NBDA6YRZkpnsLK1ThRjqBP+QrmVSwhjGzS20PkZzwJ9b1Jj3U= Authentication-Results: vger.kernel.org; dkim=none (message not signed) header.d=none; vger.kernel.org; dmarc=none action=none header.from=nxp.com; Received: from VI1PR04MB5136.eurprd04.prod.outlook.com (2603:10a6:803:55::19) by VI1PR0401MB2685.eurprd04.prod.outlook.com (2603:10a6:800:58::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Mon, 23 Aug 2021 21:23:16 +0000 Received: from VI1PR04MB5136.eurprd04.prod.outlook.com ([fe80::109:1995:3e6b:5bd0]) by VI1PR04MB5136.eurprd04.prod.outlook.com ([fe80::109:1995:3e6b:5bd0%2]) with mapi id 15.20.4436.025; Mon, 23 Aug 2021 21:23:16 +0000 From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Florian Fainelli , Andrew Lunn , Vivien Didelot , Vladimir Oltean , Tobias Waldekranz , Kurt Kanzenbach , =?utf-8?q?Alvin_=C5=A0ipraga?= Subject: [PATCH v2 net-next 3/4] net: dsa: don't advertise 'rx-vlan-filter' when not needed Date: Tue, 24 Aug 2021 00:22:57 +0300 Message-Id: <20210823212258.3190699-4-vladimir.oltean@nxp.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210823212258.3190699-1-vladimir.oltean@nxp.com> References: <20210823212258.3190699-1-vladimir.oltean@nxp.com> X-ClientProxiedBy: AM3PR05CA0150.eurprd05.prod.outlook.com (2603:10a6:207:3::28) To VI1PR04MB5136.eurprd04.prod.outlook.com (2603:10a6:803:55::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost.localdomain (188.25.144.60) by AM3PR05CA0150.eurprd05.prod.outlook.com (2603:10a6:207:3::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.18 via Frontend Transport; Mon, 23 Aug 2021 21:23:15 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7cd2cdc1-77d7-4f9d-d936-08d9667c3887 X-MS-TrafficTypeDiagnostic: VI1PR0401MB2685: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: DTVzPXD7dR6/93dpTqJzOflkWNQyz9d4LDGKtsbf3ja1lncoJwvjJqCV1HgjJbI/4sZQykYcRhsxV2efYcA1NykbAUeDRj458k/U81b07BcHQJxOBB+pqhCSEncWcgCLUw5yANmXuT8L0fxOnB+gF1DHg8lN3TJAyu2l9HczeRcBgzWA7v6q44e2ErF2AG6wX9XYJmI22sGQFvZrhXU72N4iWA7baU/KQKg3jbJ/oIqhf8eh73+ixupoD4iXsoUy52fOxyab5sSPkmhyIM8APCcFkzMEeLA9dwhB66thYtKfafAiUDDJAOmK6THyXk6EO2S6bVIkamaN2rpVNFgZT7uU4D9Wi/HCgtNNfZMGB45Xk64x6bL2qHQKxHIty/PxGoHBmDHixy3glDO0oMthw9uQetRRrLv2jnRi4L+hufIJPcy0eGGRdZPx9/mkQxKE04+ScIYp4698OWdLlre9xupmm+vJpzRB4kyWaHca+HJWAOwG24No0qa9+XgLCHqz5NpcqQ/9E3ZhvCPCHGi/f5XXCf2XP5Y5ZKKT3xl83RLK1Bal2O6T9YkqJf+trYSRovk8C0tXGyTXQOrByYuK9+FFipjjUCpvDUK8Xb7+lYMTmkQlMQppHmegluaEQ577reBGEFv2QQA34LaO2+IabuQuA7rswOuD2LxYqm/Aa0UdIOjMjobLsBQzlcgaqLqRRvTW3Fh3jOgi1TSeMjgsOQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5136.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(376002)(366004)(346002)(396003)(136003)(86362001)(66476007)(66946007)(66556008)(316002)(6916009)(54906003)(478600001)(83380400001)(66574015)(38100700002)(2906002)(38350700002)(186003)(36756003)(5660300002)(1076003)(6512007)(8936002)(6506007)(2616005)(956004)(6666004)(4326008)(44832011)(52116002)(6486002)(26005)(8676002)(30864003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?q?3xLg48Nj2ADo0QRlaALEFKK8Y?= =?utf-8?q?V5H+cwgskoepuCzp/tk3lFm20vyEbWul7Wx8Th2T2i4qEJkHxOa8YTEP?= =?utf-8?q?IDz7iqZmbl6jDZuKwKebvt6WoBSobWDkvUCYgApXGKEMZpNueNSS6O2J?= =?utf-8?q?rz4mNKQWDJPnU0CnaLE+gFrWjVKjENjmcnc6XpyE9HbIgjdeabwde+o9?= =?utf-8?q?qZP2SHrksqbZ3SdTvgo3Hu727JFH6uh8AuNT6irHO1TP7dhyatVa5wI9?= =?utf-8?q?tNhkfn43nAdalQcfN00CHTBDvAzsufqNA5dFNxsygnt2altLWMuaeZk9?= =?utf-8?q?RahrTXUFxuZe+z6meamBADgpQ2FD5168kqJPVbAMeMw9T7qXxtH6LilS?= =?utf-8?q?nWN4q7HaVzrhGqtbY8arx2IUFGdbKVPlUOZyJ1AJ9Kv2wTMPMD5c7bxz?= =?utf-8?q?a1PGRs/ObH6u7K+u7xNjN9VoqK21nU4m6m66284RYnryuA2IYqlRjp8e?= =?utf-8?q?arV/OjIIbmIiSOFKPBvZg52CtxQY+RoSOeSfKFDKKA2UqayuAWh2IrlB?= =?utf-8?q?3Ahi25ZjFzB4ex03P+PEF+ByE2OwIJB7cB2XOjnDUQ/0HKBrT+SibXjg?= =?utf-8?q?fvlftTYS6c8XmUhdq4zBa6GHl1tUKFNCQHCOKNOxC2O1MVpSo0lwVeCs?= =?utf-8?q?qNNydCt/g7sU22pAG+qrYyvrpP9cY25SJG/WZTBvFC9iLWUMXQJAT4l4?= =?utf-8?q?YBAcPGWMHUTmln26EYN0VhH7OzMR8OmCaWDsGdv21l2dPErOyD1B3/f4?= =?utf-8?q?Gp8dLtfXWKMD09lNA6O86qdFw8T8BFczpcE3Zk49rjbQ687ztgM97j31?= =?utf-8?q?cxwqwc11LNH/kZaVIsBSl70f3swmcF+XVg+lGQR196w12yXfVpoWZmsJ?= =?utf-8?q?6TDLKTAlwHIYvezdn5gOeSfKaChFSGn7Dm8b6zL126R3biOac/6Zc2Nx?= =?utf-8?q?yBwwkx36jzajqt4c20HP8SBjjPSrpyeNDqKpdXs/5NiBn7LeZqKYb9uc?= =?utf-8?q?q5BK6F0jb0lRBe+gpImsCocZOXj+OqNas71Q4o4WRXT/iL790Kz8fors?= =?utf-8?q?PDfeZ+lj/jlqFMfwtakp4bQGRGvqTWvxNsM5250bvDCrRCTPbwCv+BKG?= =?utf-8?q?dq6H3BElzUlAI1yumyfybAasW5PBKiWuFDjqFaEX9iq2AfM/OJx02qbY?= =?utf-8?q?SsYZ0WE147TiQAW5+QePUZ8Ww2GACZ1Wd3e1ztZ46i10NbZ8U4ZIP0nO?= =?utf-8?q?9kpnY7V57ojw78A79RhdiIEPRcELmJffSKUI30aW3CkpOpTvDovZDwP4?= =?utf-8?q?m8mDFDz9d6A41X4JmV2LMS/29oKRGtuP8XJJ9TmdE7RUEfZetXohdFAo?= =?utf-8?q?aA0G/ehieXqsIWemwOh0Bh8Qh9IGYDY?= X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7cd2cdc1-77d7-4f9d-d936-08d9667c3887 X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Aug 2021 21:23:16.1989 (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: 34nikoQ95rcLrQVASPygA/S9Be20JivygmQERh+kh107puqzR4VqM3Z2JgL9wO8rb4mkIG0DqQF6fuok6hzaaw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2685 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org There have been multiple independent reports about dsa_slave_vlan_rx_add_vid being called (and consequently calling the drivers' .port_vlan_add) when it isn't needed, and sometimes (not always) causing problems in the process. Case 1: mv88e6xxx_port_vlan_prepare is stubborn and only accepts VLANs on bridged ports. That is understandably so, because standalone mv88e6xxx ports are VLAN-unaware, and VTU entries are said to be a scarce resource. Otherwise said, the following fails lamentably on mv88e6xxx: ip link add br0 type bridge vlan_filtering 1 ip link set lan3 master br0 ip link add link lan10 name lan10.1 type vlan id 1 [485256.724147] mv88e6085 d0032004.mdio-mii:12: p10: hw VLAN 1 already used by port 3 in br0 RTNETLINK answers: Operation not supported This has become a worse issue since commit 9b236d2a69da ("net: dsa: Advertise the VLAN offload netdev ability only if switch supports it"). Up to that point, the driver was returning -EOPNOTSUPP and DSA was reconverting that error to 0, making the 8021q upper think all is ok (but obviously the error message was there even prior to this change). After that change the -EOPNOTSUPP is propagated to vlan_vid_add, and it is a hard error. Case 2: Ports that don't offload the Linux bridge (have a dp->bridge_dev = NULL because they don't implement .port_bridge_{join,leave}). Understandably, a standalone port should not offload VLANs either, it should remain VLAN unaware and any VLAN should be a software VLAN (as long as the hardware is not quirky, that is). In fact, dsa_slave_port_obj_add does do the right thing and rejects switchdev VLAN objects coming from the bridge when that bridge is not offloaded: case SWITCHDEV_OBJ_ID_PORT_VLAN: if (!dsa_port_offloads_bridge_port(dp, obj->orig_dev)) return -EOPNOTSUPP; err = dsa_slave_vlan_add(dev, obj, extack); But it seems that the bridge is able to trick us. The __vlan_vid_add from br_vlan.c has: /* Try switchdev op first. In case it is not supported, fallback to * 8021q add. */ err = br_switchdev_port_vlan_add(dev, v->vid, flags, extack); if (err == -EOPNOTSUPP) return vlan_vid_add(dev, br->vlan_proto, v->vid); So it says "no, no, you need this VLAN in your life!". And we, naive as we are, say "oh, this comes from the vlan_vid_add code path, it must be an 8021q upper, sure, I'll take that". And we end up with that bridge VLAN installed on our port anyway. But this time, it has the wrong flags: if the bridge was trying to install VLAN 1 as a pvid/untagged VLAN, failed via switchdev, retried via vlan_vid_add, we have this comment: /* This API only allows programming tagged, non-PVID VIDs */ So what we do makes absolutely no sense. Backtracing a bit, we see the common pattern. We allow the network stack to think that our standalone ports are VLAN-aware, but they aren't, for the vast majority of switches. The quirky ones should not dictate the norm. The dsa_slave_vlan_rx_add_vid and dsa_slave_vlan_rx_kill_vid methods exist for drivers that need the 'rx-vlan-filter: on' feature in ethtool -k, which can be due to any of the following reasons: 1. vlan_filtering_is_global = true, and some ports are under a VLAN-aware bridge while others are standalone, and the standalone ports would otherwise drop VLAN-tagged traffic. This is described in commit 061f6a505ac3 ("net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation"). 2. the ports that are under a VLAN-aware bridge should also set this feature, for 8021q uppers having a VID not claimed by the bridge. In this case, the driver will essentially not even know that the VID is coming from the 8021q layer and not the bridge. 3. Hellcreek. This driver needs it because in standalone mode, it uses unique VLANs per port to ensure separation. For separation of untagged traffic, it uses different PVIDs for each port, and for separation of VLAN-tagged traffic, it never accepts 8021q uppers with the same vid on two ports. If a driver does not fall under any of the above 3 categories, there is no reason why it should advertise the 'rx-vlan-filter' feature, therefore no reason why it should offload the VLANs added through vlan_vid_add. This commit fixes the problem by removing the 'rx-vlan-filter' feature from the slave devices when they operate in standalone mode, and when they offload a VLAN-unaware bridge. The way it works is that vlan_vid_add will now stop its processing here: vlan_add_rx_filter_info: if (!vlan_hw_filter_capable(dev, proto)) return 0; So the VLAN will still be saved in the interface's VLAN RX filtering list, but because it does not declare VLAN filtering in its features, the 8021q module will return zero without committing that VLAN to hardware. This gives the drivers what they want, since it keeps the 8021q VLANs away from the VLAN table until VLAN awareness is enabled (point at which the ports are no longer standalone, hence in the mv88e6xxx case, the check in mv88e6xxx_port_vlan_prepare passes). Since the issue predates the existence of the hellcreek driver, case 3 will be dealt with in a separate patch. The main change that this patch makes is to no longer set NETIF_F_HW_VLAN_CTAG_FILTER unconditionally, but toggle it dynamically (for most switches, never). The second part of the patch addresses an issue that the first part introduces: because the 'rx-vlan-filter' feature is now dynamically toggled, and our .ndo_vlan_rx_add_vid does not get called when 'rx-vlan-filter' is off, we need to avoid bugs such as the following by replaying the VLANs from 8021q uppers every time we enable VLAN filtering: ip link add link lan0 name lan0.100 type vlan id 100 ip addr add 192.168.100.1/24 dev lan0.100 ping 192.168.100.2 # should work ip link add br0 type bridge vlan_filtering 0 ip link set lan0 master br0 ping 192.168.100.2 # should still work ip link set br0 type bridge vlan_filtering 1 ping 192.168.100.2 # should still work but doesn't As reported by Florian, some drivers look at ds->vlan_filtering in their .port_vlan_add() implementation. So this patch also makes sure that ds->vlan_filtering is committed before calling the driver. This is the reason why it is first committed, then restored on the failure path. Reported-by: Tobias Waldekranz Reported-by: Alvin Šipraga Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Tested-by: Florian Fainelli --- v1->v2: remove the unused "ds" variable from dsa_slave_setup_tagger net/dsa/dsa_priv.h | 2 ++ net/dsa/port.c | 42 +++++++++++++++++++++++++-- net/dsa/slave.c | 72 ++++++++++++++++++++++++++++++++++++++++++++-- 3 files changed, 111 insertions(+), 5 deletions(-) diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h index 88aaf43b2da4..33ab7d7af9eb 100644 --- a/net/dsa/dsa_priv.h +++ b/net/dsa/dsa_priv.h @@ -320,6 +320,8 @@ int dsa_slave_register_notifier(void); void dsa_slave_unregister_notifier(void); void dsa_slave_setup_tagger(struct net_device *slave); int dsa_slave_change_mtu(struct net_device *dev, int new_mtu); +int dsa_slave_manage_vlan_filtering(struct net_device *dev, + bool vlan_filtering); static inline struct dsa_port *dsa_slave_to_port(const struct net_device *dev) { diff --git a/net/dsa/port.c b/net/dsa/port.c index 3b775d7adee2..616330a16d31 100644 --- a/net/dsa/port.c +++ b/net/dsa/port.c @@ -580,6 +580,7 @@ static bool dsa_port_can_apply_vlan_filtering(struct dsa_port *dp, int dsa_port_vlan_filtering(struct dsa_port *dp, bool vlan_filtering, struct netlink_ext_ack *extack) { + bool old_vlan_filtering = dsa_port_is_vlan_filtering(dp); struct dsa_switch *ds = dp->ds; bool apply; int err; @@ -605,12 +606,49 @@ int dsa_port_vlan_filtering(struct dsa_port *dp, bool vlan_filtering, if (err) return err; - if (ds->vlan_filtering_is_global) + if (ds->vlan_filtering_is_global) { + int port; + ds->vlan_filtering = vlan_filtering; - else + + for (port = 0; port < ds->num_ports; port++) { + struct net_device *slave; + + if (!dsa_is_user_port(ds, port)) + continue; + + /* We might be called in the unbind path, so not + * all slave devices might still be registered. + */ + slave = dsa_to_port(ds, port)->slave; + if (!slave) + continue; + + err = dsa_slave_manage_vlan_filtering(slave, + vlan_filtering); + if (err) + goto restore; + } + } else { dp->vlan_filtering = vlan_filtering; + err = dsa_slave_manage_vlan_filtering(dp->slave, + vlan_filtering); + if (err) + goto restore; + } + return 0; + +restore: + ds->ops->port_vlan_filtering(ds, dp->index, old_vlan_filtering, NULL); + + if (ds->vlan_filtering_is_global) + ds->vlan_filtering = old_vlan_filtering; + else + dp->vlan_filtering = old_vlan_filtering; + + return err; } /* This enforces legacy behavior for switch drivers which assume they can't diff --git a/net/dsa/slave.c b/net/dsa/slave.c index f785d24fcf23..f71d31d3aab4 100644 --- a/net/dsa/slave.c +++ b/net/dsa/slave.c @@ -1409,6 +1409,75 @@ static int dsa_slave_vlan_rx_kill_vid(struct net_device *dev, __be16 proto, return 0; } +static int dsa_slave_restore_vlan(struct net_device *vdev, int vid, void *arg) +{ + __be16 proto = vdev ? vlan_dev_vlan_proto(vdev) : htons(ETH_P_8021Q); + + return dsa_slave_vlan_rx_add_vid(arg, proto, vid); +} + +static int dsa_slave_clear_vlan(struct net_device *vdev, int vid, void *arg) +{ + __be16 proto = vdev ? vlan_dev_vlan_proto(vdev) : htons(ETH_P_8021Q); + + return dsa_slave_vlan_rx_kill_vid(arg, proto, vid); +} + +/* Keep the VLAN RX filtering list in sync with the hardware only if VLAN + * filtering is enabled. The baseline is that only ports that offload a + * VLAN-aware bridge are VLAN-aware, and standalone ports are VLAN-unaware, + * but there are exceptions for quirky hardware. + * + * If ds->vlan_filtering_is_global = true, then standalone ports which share + * the same switch with other ports that offload a VLAN-aware bridge are also + * inevitably VLAN-aware. + * + * To summarize, a DSA switch port offloads: + * + * - If standalone (this includes software bridge, software LAG): + * - if ds->vlan_filtering_is_global = true AND there are bridges spanning + * this switch chip which have vlan_filtering=1: + * - the 8021q upper VLANs + * - else (VLAN filtering is not global, or it is, but no port is under a + * VLAN-aware bridge): + * - no VLAN (any 8021q upper is a software VLAN) + * + * - If under a vlan_filtering=0 bridge which it offload: + * - if ds->configure_vlan_while_not_filtering = true (default): + * - the bridge VLANs. These VLANs are committed to hardware but inactive. + * - else (deprecated): + * - no VLAN. The bridge VLANs are not restored when VLAN awareness is + * enabled, so this behavior is broken and discouraged. + * + * - If under a vlan_filtering=1 bridge which it offload: + * - the bridge VLANs + * - the 8021q upper VLANs + */ +int dsa_slave_manage_vlan_filtering(struct net_device *slave, + bool vlan_filtering) +{ + int err; + + if (vlan_filtering) { + slave->features |= NETIF_F_HW_VLAN_CTAG_FILTER; + + err = vlan_for_each(slave, dsa_slave_restore_vlan, slave); + if (err) { + vlan_for_each(slave, dsa_slave_clear_vlan, slave); + slave->features &= ~NETIF_F_HW_VLAN_CTAG_FILTER; + return err; + } + } else { + err = vlan_for_each(slave, dsa_slave_clear_vlan, slave); + if (err) + return err; + + slave->features &= ~NETIF_F_HW_VLAN_CTAG_FILTER; + } + + return 0; +} + struct dsa_hw_port { struct list_head list; struct net_device *dev; @@ -1802,7 +1871,6 @@ void dsa_slave_setup_tagger(struct net_device *slave) struct dsa_slave_priv *p = netdev_priv(slave); const struct dsa_port *cpu_dp = dp->cpu_dp; struct net_device *master = cpu_dp->master; - const struct dsa_switch *ds = dp->ds; slave->needed_headroom = cpu_dp->tag_ops->needed_headroom; slave->needed_tailroom = cpu_dp->tag_ops->needed_tailroom; @@ -1816,8 +1884,6 @@ void dsa_slave_setup_tagger(struct net_device *slave) p->xmit = cpu_dp->tag_ops->xmit; slave->features = master->vlan_features | NETIF_F_HW_TC; - if (ds->ops->port_vlan_add && ds->ops->port_vlan_del) - slave->features |= NETIF_F_HW_VLAN_CTAG_FILTER; slave->hw_features |= NETIF_F_HW_TC; slave->features |= NETIF_F_LLTX; if (slave->needed_tailroom) From patchwork Mon Aug 23 21:22:58 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 502196 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-18.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, MSGID_FROM_MTA_HEADER, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C64DCC4338F for ; Mon, 23 Aug 2021 21:23:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id ADDCA613AD for ; Mon, 23 Aug 2021 21:23:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232898AbhHWVYU (ORCPT ); Mon, 23 Aug 2021 17:24:20 -0400 Received: from mail-eopbgr30042.outbound.protection.outlook.com ([40.107.3.42]:5229 "EHLO EUR03-AM5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S232829AbhHWVYD (ORCPT ); Mon, 23 Aug 2021 17:24:03 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kZO0U/Uf0UtNSFpiUBCvwTUxyW5B8T2IG0eb7RulKELzhCoeIWG6fkVKyQminvH9Ekn4Qhw4oStNpLCfMOGnxbCV6t3LSn1XPDdFMnWi8yMHyfepbo657hQnVfwItpLxzukvrIKpRqjmhGRGIUmFYM5RXFwlkSiB8+szC7Mu06N9jpHYgzwbCKJ4ZyJwptFnirn8iNLYLGQJOrLsJjsU9r2c/OqTzjsTSyweUiQze3nXvK6zxdmWk50kYvq9uf4Rle+UsJssUXNeDI4MSKF5O6NmmMAVydjltU6cgIXmIZDepwI/oktoO0jMSuNDJ+48GBhTQ9kP8w5lgcKttSN+AQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QAnOLn1LPPE32yMQXZwy2x5sztBRKfYMiUoKd31srao=; b=SgSOVdbhFtUuMyAcF226S28ZTtMtMO7L81FCOby8Sx9JsAwj/+IbqZwmCufaahn6Cx6C3RcNE9Tn2KXCo4oajImcHy3RxzmPBSjphAs4fKGyV1OM+WqOj6zJDv3iqMuzgl66mjMEwpJBwNdqt/rAFuTdyEUBYuo94T7xcBPQImkTeBD+7zNNB703+wX5DtRegkaQsDDr5JRFJpZPuhZ5gNcLn6X5mlOIR+z7wN2Cy63GYTauIRMFre/xqXJTcKOGG1bBeUcZwYnzTwoiineGNSil5Qng/aNtt1Aojoj2JveJmUBGUh33Zfv2wHzLPryYD6U77O6guhPYq2TD1bGBVg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QAnOLn1LPPE32yMQXZwy2x5sztBRKfYMiUoKd31srao=; b=p9G/Z40A/voBmwJB3zxGaQYjynkIMABd2y+nl17tMWVfhW7yudovoNWZsZxPpIF+ooQleXpq/sic/xKmh4rjE8GtN1EzbHbOv1TUkAkRrwLXgHpVwpxsWriF3zbGVnbO/85E69AbkxHwlCuEh5tz+mlcsReqp3RaZL7P3Eu/dHg= Authentication-Results: vger.kernel.org; dkim=none (message not signed) header.d=none; vger.kernel.org; dmarc=none action=none header.from=nxp.com; Received: from VI1PR04MB5136.eurprd04.prod.outlook.com (2603:10a6:803:55::19) by VI1PR0401MB2685.eurprd04.prod.outlook.com (2603:10a6:800:58::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Mon, 23 Aug 2021 21:23:17 +0000 Received: from VI1PR04MB5136.eurprd04.prod.outlook.com ([fe80::109:1995:3e6b:5bd0]) by VI1PR04MB5136.eurprd04.prod.outlook.com ([fe80::109:1995:3e6b:5bd0%2]) with mapi id 15.20.4436.025; Mon, 23 Aug 2021 21:23:17 +0000 From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Florian Fainelli , Andrew Lunn , Vivien Didelot , Vladimir Oltean , Tobias Waldekranz , Kurt Kanzenbach , =?utf-8?q?Alvin_=C5=A0ipraga?= Subject: [PATCH v2 net-next 4/4] net: dsa: let drivers state that they need VLAN filtering while standalone Date: Tue, 24 Aug 2021 00:22:58 +0300 Message-Id: <20210823212258.3190699-5-vladimir.oltean@nxp.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210823212258.3190699-1-vladimir.oltean@nxp.com> References: <20210823212258.3190699-1-vladimir.oltean@nxp.com> X-ClientProxiedBy: AM3PR05CA0150.eurprd05.prod.outlook.com (2603:10a6:207:3::28) To VI1PR04MB5136.eurprd04.prod.outlook.com (2603:10a6:803:55::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost.localdomain (188.25.144.60) by AM3PR05CA0150.eurprd05.prod.outlook.com (2603:10a6:207:3::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.18 via Frontend Transport; Mon, 23 Aug 2021 21:23:16 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ee573cd1-7701-474e-91a6-08d9667c3921 X-MS-TrafficTypeDiagnostic: VI1PR0401MB2685: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: DP+l8LJPv94sgxcmKorWmAv+quKbwfaEI/DJtDpPruXg4g5c12poFdu+fbpm2J7b9UF46+Q/lhYvZJYKj0svDE7uom5a0s7bRSjWdqYVOcgl4c//rWw4qYQoVsfzpwr8xl1n45oOxdDOhml0H/AgZYBxeJ/zvWSnWu99TxvpoRPyoaoFa5PUBeXtWAgmRJeWfCpo4Tt+YZJlGAU/olz9v0vBHmNq5UCeXfMqZPdN/oA9cxg6Z6mOYfdOMtXh76OQiaQEDnv7rZQjWYyhBO0LmOBtSw4w3W6oZqg58aG54QeTa7pNuUMa26h2dT08r7opmQI7afP17OtB21rpOFeF4WqFDTpVrepPDXjJLup9UmWglHC4erXJBSV7WBi10Sy3/NHXA7Gj0kAbYMOQQ0hNcbgK8wWOqretUoV75Fd4GbhUQdnU+5Lr26NP4LnR+NtzvVdoTClEjrHFqt2iA3tf7Wx/mLe5zsziOvqToNCp9onT3vmSU1/cjVY/xaQ+ZHccbGg419XVp+S3Jmhd9ctAfJoP6s7ANOMETP/w91OxSeyaSJ5MDzAUzS3nIv1CH/7d+g9JQTzaFZf5h77lLLtYUxljpQYfLN5QTxVaoCIbcFvJ3xwEvtbaflNAkR3j3xoxVOJYZKRxymfBlNCeRV9gw2897vfQp997D2TeqMmG7osjWNdhKNgQOgQA96iONBI4yUKADS6msbBN7uZxuJhUJQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5136.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(376002)(366004)(346002)(396003)(136003)(86362001)(66476007)(66946007)(66556008)(316002)(6916009)(54906003)(478600001)(83380400001)(38100700002)(2906002)(38350700002)(186003)(36756003)(5660300002)(1076003)(6512007)(8936002)(6506007)(2616005)(956004)(6666004)(4326008)(44832011)(52116002)(6486002)(26005)(8676002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: axGpIntOp2CAlxE7ZSjcESQXISKPffVnwrIMkvi18UyUp4FFFUCcLjGZB+ZQlli72Hiy7J/Kv8USKBTjXTC6y0DsifM/BkTNEuEhGPrJY9NRMN8Hhwc5l6I+5GSpxlUmNlGOMlR4Aq7eOPE3mEHYlAmu1WAvogqHjos0RZPJO3lqTa92bPLsvtwHuBsfvuM1jYEvkquPAq99LfAiYo7Rmq+RRHs431cwXYtEHWYlOar9bGaW5UaXEOcVzmNERMNMStv7n7T1DrMZSbPpPLGkvX0slNlagepUMKXca2nQc66SKKVsKS09S1ifVcT0bV9ug4CYdjUqDlTmqyOjRamWoWbklwLdnoWjTZUVUvgZX/ul24O2oO9MxYIHWlJt05BVUtFn/2nf3bYcHZQfoZBR/leAIpvbbR2nCCHggeeduzJaI9Ll7oeU55LqKa7ZAlg4RoRYh+edSGUOmn6yAVmx8i9ZUbEUs9H3ENm8lv6HrrT+whVVfNcEgfsbNEUW0+u7tGQj4k1kmJe4Donqg8PanrWzijGwW2iI9diSLF0Rf5bdOpMRGS0w6D337l8YOok673rjeCbbzNSMh4GVCFKZKnL9bPBR68WsHE6ka9YSJmIwVPFE39mnLFIVOPn3tSawEK88xh5WxzpheG/vAYu+10Dk8hVRBhkoAvt/A/7LxwlOTK7WTDd3QZcguAvU3qaLP9LAuhHQtz7IEYIoYEe1o6r0jXZPZW28vteYVengPKr3pCqgGh4vwtQiZxaUpkFeLWdfaCe8YcHlb8yZ62iPDBa2uIy3aaE6663TW8Q6CNA/Apazy0101xoQKjRzOtvkBe2NnPVzswJkiFIW4SULp8jtGm1zRFvNnMjacqKqPpu1SWiztuCLiU+l1om6vwXn290/IO8xozFYQqU5cfbBh5sbqz8luiQSexvOvlBSNInTdT1bCUtOYDg+F+IDCZgYyhEk3L6uuIY+4IC5i5Ke8eaDsKFM7+biQ+u4/0F16SRh2sE4+BdgL0FxLCNbpDx8+rgJYiYH3Zxn4IO1u5F3OI7IgEwdPXjUGY07FBMtPsipT6n8KNFsGuudLETtzVGjQLNaUm7NycBH3/c2EK42eeM9y5TlJN+hVnQX9UkGNaPqj8SEvjxIXTFmWVMypEgSYvVsvKMrpCOFTRAEqxrmgu5Xi8jSxKBZxgn7yN9S9ythU+pxCFiB3VhxIjEeEY2zzQzdhQ6kAiqpZomPtnCeUJCWhlW45QxweIDeCWzZI9+Ye7qf/5X1gSy02TF4J009oNQSClBCAvWKos5hi8GgFDy2U722eqSo6CWMTiGPRIk5oKAABxs6YiqUeezJIi+3 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: ee573cd1-7701-474e-91a6-08d9667c3921 X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Aug 2021 21:23:17.1494 (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: Ig3ftxqg06IGD8LnfOaWVHOXvq2gQ5j3ySzd6baH2ELAYKWNqk0nsH4bRkeE1MskjhAWmpX+CFEknuQLj7Ik+g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2685 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org As explained in commit e358bef7c392 ("net: dsa: Give drivers the chance to veto certain upper devices"), the hellcreek driver uses some tricks to comply with the network stack expectations: it enforces port separation in standalone mode using VLANs. For untagged traffic, bridging between ports is prevented by using different PVIDs, and for VLAN-tagged traffic, it never accepts 8021q uppers with the same VID on two ports, so packets with one VLAN cannot leak from one port to another. That is almost fine*, and has worked because hellcreek relied on an implicit behavior of the DSA core that was changed by the previous patch: the standalone ports declare the 'rx-vlan-filter' feature as 'on [fixed]'. Since most of the DSA drivers are actually VLAN-unaware in standalone mode, that feature was actually incorrectly reflecting the hardware/driver state, so there was a desire to fix it. This leaves the hellcreek driver in a situation where it has to explicitly request this behavior from the DSA framework. We configure the ports as follows: - Standalone: 'rx-vlan-filter' is on. An 8021q upper on top of a standalone hellcreek port will go through dsa_slave_vlan_rx_add_vid and will add a VLAN to the hardware tables, giving the driver the opportunity to refuse it through .port_prechangeupper. - Bridged with vlan_filtering=0: 'rx-vlan-filter' is off. An 8021q upper on top of a bridged hellcreek port will not go through dsa_slave_vlan_rx_add_vid, because there will not be any attempt to offload this VLAN. The driver already disables VLAN awareness, so that upper should receive the traffic it needs. - Bridged with vlan_filtering=1: 'rx-vlan-filter' is on. An 8021q upper on top of a bridged hellcreek port will call dsa_slave_vlan_rx_add_vid, and can again be vetoed through .port_prechangeupper. *It is not actually completely fine, because if I follow through correctly, we can have the following situation: ip link add br0 type bridge vlan_filtering 0 ip link set lan0 master br0 # lan0 now becomes VLAN-unaware ip link set lan0 nomaster # lan0 fails to become VLAN-aware again, therefore breaking isolation This patch fixes that corner case by extending the DSA core logic, based on this requested attribute, to change the VLAN awareness state of the switch (port) when it leaves the bridge. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Acked-by: Kurt Kanzenbach --- v1->v2: put back the "ds" variable in dsa_slave_setup_tagger drivers/net/dsa/hirschmann/hellcreek.c | 1 + include/net/dsa.h | 3 +++ net/dsa/slave.c | 12 ++++++++---- net/dsa/switch.c | 21 ++++++++++++++++----- 4 files changed, 28 insertions(+), 9 deletions(-) diff --git a/drivers/net/dsa/hirschmann/hellcreek.c b/drivers/net/dsa/hirschmann/hellcreek.c index 5c54ae1be62c..3faff95fd49f 100644 --- a/drivers/net/dsa/hirschmann/hellcreek.c +++ b/drivers/net/dsa/hirschmann/hellcreek.c @@ -1345,6 +1345,7 @@ static int hellcreek_setup(struct dsa_switch *ds) * filtering setups are not supported. */ ds->vlan_filtering_is_global = true; + ds->needs_standalone_vlan_filtering = true; /* Intercept _all_ PTP multicast traffic */ ret = hellcreek_setup_fdb(hellcreek); diff --git a/include/net/dsa.h b/include/net/dsa.h index c7ea0f61056f..f9a17145255a 100644 --- a/include/net/dsa.h +++ b/include/net/dsa.h @@ -363,6 +363,9 @@ struct dsa_switch { */ bool vlan_filtering_is_global; + /* Keep VLAN filtering enabled on ports not offloading any upper. */ + bool needs_standalone_vlan_filtering; + /* Pass .port_vlan_add and .port_vlan_del to drivers even for bridges * that have vlan_filtering=0. All drivers should ideally set this (and * then the option would get removed), but it is unknown whether this diff --git a/net/dsa/slave.c b/net/dsa/slave.c index f71d31d3aab4..662ff531d4e2 100644 --- a/net/dsa/slave.c +++ b/net/dsa/slave.c @@ -1435,11 +1435,12 @@ static int dsa_slave_clear_vlan(struct net_device *vdev, int vid, void *arg) * To summarize, a DSA switch port offloads: * * - If standalone (this includes software bridge, software LAG): - * - if ds->vlan_filtering_is_global = true AND there are bridges spanning - * this switch chip which have vlan_filtering=1: + * - if ds->needs_standalone_vlan_filtering = true, OR if + * (ds->vlan_filtering_is_global = true AND there are bridges spanning + * this switch chip which have vlan_filtering=1) * - the 8021q upper VLANs - * - else (VLAN filtering is not global, or it is, but no port is under a - * VLAN-aware bridge): + * - else (standalone VLAN filtering is not needed, VLAN filtering is not + * global, or it is, but no port is under a VLAN-aware bridge): * - no VLAN (any 8021q upper is a software VLAN) * * - If under a vlan_filtering=0 bridge which it offload: @@ -1871,6 +1872,7 @@ void dsa_slave_setup_tagger(struct net_device *slave) struct dsa_slave_priv *p = netdev_priv(slave); const struct dsa_port *cpu_dp = dp->cpu_dp; struct net_device *master = cpu_dp->master; + const struct dsa_switch *ds = dp->ds; slave->needed_headroom = cpu_dp->tag_ops->needed_headroom; slave->needed_tailroom = cpu_dp->tag_ops->needed_tailroom; @@ -1888,6 +1890,8 @@ void dsa_slave_setup_tagger(struct net_device *slave) slave->features |= NETIF_F_LLTX; if (slave->needed_tailroom) slave->features &= ~(NETIF_F_SG | NETIF_F_FRAGLIST); + if (ds->needs_standalone_vlan_filtering) + slave->features |= NETIF_F_HW_VLAN_CTAG_FILTER; } static struct lock_class_key dsa_slave_netdev_xmit_lock_key; diff --git a/net/dsa/switch.c b/net/dsa/switch.c index dd042fd7f800..1c797ec8e2c2 100644 --- a/net/dsa/switch.c +++ b/net/dsa/switch.c @@ -116,9 +116,10 @@ static int dsa_switch_bridge_join(struct dsa_switch *ds, static int dsa_switch_bridge_leave(struct dsa_switch *ds, struct dsa_notifier_bridge_info *info) { - bool unset_vlan_filtering = br_vlan_enabled(info->br); struct dsa_switch_tree *dst = ds->dst; struct netlink_ext_ack extack = {0}; + bool change_vlan_filtering = false; + bool vlan_filtering; int err, port; if (dst->index == info->tree_index && ds->index == info->sw_index && @@ -131,6 +132,15 @@ static int dsa_switch_bridge_leave(struct dsa_switch *ds, info->sw_index, info->port, info->br); + if (ds->needs_standalone_vlan_filtering && !br_vlan_enabled(info->br)) { + change_vlan_filtering = true; + vlan_filtering = true; + } else if (!ds->needs_standalone_vlan_filtering && + br_vlan_enabled(info->br)) { + change_vlan_filtering = true; + vlan_filtering = false; + } + /* If the bridge was vlan_filtering, the bridge core doesn't trigger an * event for changing vlan_filtering setting upon slave ports leaving * it. That is a good thing, because that lets us handle it and also @@ -139,21 +149,22 @@ static int dsa_switch_bridge_leave(struct dsa_switch *ds, * vlan_filtering callback is only when the last port leaves the last * VLAN-aware bridge. */ - if (unset_vlan_filtering && ds->vlan_filtering_is_global) { + if (change_vlan_filtering && ds->vlan_filtering_is_global) { for (port = 0; port < ds->num_ports; port++) { struct net_device *bridge_dev; bridge_dev = dsa_to_port(ds, port)->bridge_dev; if (bridge_dev && br_vlan_enabled(bridge_dev)) { - unset_vlan_filtering = false; + change_vlan_filtering = false; break; } } } - if (unset_vlan_filtering) { + + if (change_vlan_filtering) { err = dsa_port_vlan_filtering(dsa_to_port(ds, info->port), - false, &extack); + vlan_filtering, &extack); if (extack._msg) dev_err(ds->dev, "port %d: %s\n", info->port, extack._msg);