From patchwork Tue Aug 24 11:40:44 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 502181 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, URIBL_BLOCKED, 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 6128BC4320E for ; Tue, 24 Aug 2021 11:41:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4D94C613AB for ; Tue, 24 Aug 2021 11:41:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236909AbhHXLmY (ORCPT ); Tue, 24 Aug 2021 07:42:24 -0400 Received: from mail-eopbgr80072.outbound.protection.outlook.com ([40.107.8.72]:17383 "EHLO EUR04-VI1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S236775AbhHXLmL (ORCPT ); Tue, 24 Aug 2021 07:42:11 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jsPZEFVbvqTdANN8um3Yp5xM4pojF3zrFUfCKwiXN5UncKaLUQyT92MEXTEtm4lFWJWr6RUK2yDfz71Sbw/Db8whIsQBE9sB8OAUSL1WYdqMp+xiJXv1vs2jIkRf6QflvS6r2+Jgxyl9EFPr9xrIEmjtk6/SeMyfNKIxE1uanAirmqq0aRQUDIM2C+iUBemQNY53lNG91M7wDRP5fM1lLyNpbYwtYDMGzsF+8I/k22UHN8PGpPlWoRx8Oq/KBFTIR3lSQoZ4hkZPGEH3yqcNAgTP4vCuxoWQLvdT+YuDD1m7IZYci6thWztELaeym4LuE73DBSD49/ny/RaVCCJvxw== 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=4/DfRfgxiFR2oP4mZD9EDUYD6S5gJ05WI2BI60CtH/U=; b=JaisdOUznEaciNmud5y5zyE6jiXK5SCyJh2ucf+ktHyvsgfynRYEXGdDOU6JQzfRxlqp4GVXMA6DFBoEmDakJ9wV2wz36AJHChWyUAopOFTH/Q/fYUIoEpnaGpklO9jKQ6fBxqcvGneAt9DS4P2till87RmDVbNeEFzuxSV60gkQYs7fN/KXQn4z2OH8r3mJM/fEXFsFj96+xUGZMqVx2GvbPGPbXWPUGIlF6gQy+8quzPFnb6Iaw1DAqSXbCBrWxD2T4bi7vqs3VN79tCFur3Dfaz5FMdO5SItlyu/Hjy5BIXaNxyMyk6XPIJHWeRstjlP9Sq8OiUO2Dv1r49cYAA== 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=4/DfRfgxiFR2oP4mZD9EDUYD6S5gJ05WI2BI60CtH/U=; b=S/uaawWe4CBZpSTU7sXdkyNKEQm3HnhBAQFlC9WDNQXQKgNyJ8nb16RFpJsTPzO92qStwdIvpt4oiE3T0xuAoz07ykfPKdI3xeE88WRk296zUiSUAWstPIuGxm97SabXxFgOqalbjLguflhwGFTdA2pnVeNt8b6gSVO8Deymxjk= 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 VI1PR04MB5696.eurprd04.prod.outlook.com (2603:10a6:803:e7::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Tue, 24 Aug 2021 11:41:18 +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; Tue, 24 Aug 2021 11:41:18 +0000 From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Florian Fainelli , Andrew Lunn , Vivien Didelot , Vladimir Oltean , UNGLinuxDriver@microchip.com, DENG Qingfang , Kurt Kanzenbach , Hauke Mehrtens , Woojung Huh , Sean Wang , Landen Chao , Alexandre Belloni , George McCollister , John Crispin , Aleksander Jan Bajkowski , Egil Hjelmeland , Oleksij Rempel Subject: [RFC PATCH net-next 3/8] net: mscc: ocelot: serialize access to the MAC table Date: Tue, 24 Aug 2021 14:40:44 +0300 Message-Id: <20210824114049.3814660-4-vladimir.oltean@nxp.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210824114049.3814660-1-vladimir.oltean@nxp.com> References: <20210824114049.3814660-1-vladimir.oltean@nxp.com> X-ClientProxiedBy: FR0P281CA0083.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:1e::18) 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 FR0P281CA0083.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:1e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.6 via Frontend Transport; Tue, 24 Aug 2021 11:41:17 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 75808a37-5b73-46c7-ee4f-08d966f4168c X-MS-TrafficTypeDiagnostic: VI1PR04MB5696: 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: SOthDhAIatxXZHf9Plcki0nbDLkpQDWdT0ueNZfgLrnAhGyW6Xs1dq+2OKwFejJ/ubKx2gRmunm3Q55lONC5kLlBGIP9KLsrVKWzYqA7RXb9agKhHMt709t9iQqbHtDNTKwk3MvkBOavsUZGpAzNdZu49LP3hm8B8h9eI65NxhkyzaSjj7MicAolejo7g54MlZQreRXlsNlF/3Q7+ls1jgC6gJBYqAVRRSo7F6iaSCofPFGwpjQ/cYtRhjiqK1iXo+uhwm+QnZnA8Sjl0gThs5T75zuE/yiOJopA9TM27iSyXxYO3oikjdV6RzU//aiac3yZeJvIyk3NNExZ7d3kNGjMhR5DGEjYSDl2BfeS3mF3tESVCC6wPAw0OC17mu8zqiQkOfJd7qCaG+69tg2FEKND0XAyqaVsHuPDekJ0FMR6/GN+G+vXhZl11e61ke1guhW+p/sZOUpngHdsiMEvruQ89hB5tQ5ejIvgC1yAu08Vjh1ajIZXL2IHBG7QOjgNtHCBO5yZQvDWlNmMKH0z/HQ10nKAh13jDytUT/Vxp3bqhORqla4TW/0v6C0A9NEF0GfWu8uKAIujm6hyllbZ271Gez7ckIMeerMWKFIz/Rxr+BtRJGKRRHpAan9UcKPtkSt3c7UWL50VMqKqYjwYqpklSGgnHyYFGVLQQ0i0ikt2rSFsixmB8jThlBfqNwlTFaLz1hfLLfTzHQFFkctMUQ== 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)(366004)(346002)(396003)(136003)(39850400004)(376002)(52116002)(4326008)(478600001)(5660300002)(6916009)(66476007)(66556008)(26005)(83380400001)(1076003)(36756003)(66946007)(6486002)(6666004)(6512007)(7416002)(6506007)(186003)(8676002)(8936002)(2616005)(86362001)(44832011)(38100700002)(38350700002)(956004)(2906002)(54906003)(316002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Ef4GXr9CCj6exwSOHXUZJjBnqgEg46w+ZkK/PG7MTfQPT59drsc3SzjILMicFwlNApz88Ho8vmaPeycKnl3FV/6zDrrnXV4lLolGgzca+x3hzwqg729X5EZ1TNMO9B8sxm/rMlOf6OHIra1+3O7NprSx6pMDXMiX2ipIe8ixtKu1qWD44QnWjnwr0qaOLhE1/x2/Wo6llpqvTMLgQo6PINNcoPRUD6jOoI0Fg5JuUbz0gmDfTuIyz2m6kPY3LndzivPdKmMmgrzqGy3M1gS0kGqzgb1PHisH7dVthnTupACK7soIxhEcE62FR38gSoVjAOXW8z+1Jlo1AsvJlZFo3HSm2qOz1OaYJX+oSQLDJCu3QB8ZNYr0ClqifwAFvhLp6sAZq+87ta42Bg8tfqFuZhRzyFAu23u4hAUgbzLX7l9Uer10vzPwJ1ixyqTNZVJpkyazKak8QmL7/xsUAT4RK/UdSIAUJy4nPuBUF3TH7rajxoWpmk7ab93vjN8nZC6DJsgdy2Yu+rOLuXoTLTOymeCIJGqEY6qszN30/j6MmT8A0Q4gaVCoR8rRpbCQyti1JzsrZOLhyR0HRiTWLtGU/Zz4pGfIq/3foUzQecQHn3R54uExwqBSQTY4SObU4L2K/xdYVERnyrolTrNO2+3bqy1eQ5MFr3RI1xVBSQ5hAIgPH3/W+mlAVcNkwnd7FOZdmHrLI06htRzhVO52zEhjI6lNxQz1mKG1xcJoCy3XWFJcV0wx6Se+0W1pNRQOhGmz6hUt/e4rgSExl6On9S+epGYTZpkkpoIksQtNwdxUE7gPTxR4Xip9J54Q5xUQsLpiH2iu/bm61ZhawaIMzDRsTTIA9lX6USXsMDJAdvUrAC37kewaabnJx+G4d5+qR+8jz0CjYEXzJSnuO+fqFLtxSpJAXsWR+4FMPaZvVVAhdpKcR3foJtGerH2yYtcYfsa+4MVpco4NCUei0kzAHEA41e0SZpFFCVthnxF8kB60rXRjQuGrUderrBFeJcW4gEkIEIH27kGOMtvJxnpyxgFFb+fj72/RjPLE5IYGL52Ii3oMXi17IC+9awhPL692DHLCUIaXmyNjscUrhGm1WjMNH4BFIIbCoWh5t4ehKf8W0F50UkrMu23j5M7uZ23hmus/pY7xTtC6qpMu+xmuO6TkYFhXIs5JP/oSgxX569W6LJr+t8aCol60lL5KQC60Gu5X8f4sWSBiRxByxSyO1C70OBwR8T1UXuwKjSfDhGL2I1bZKwai9jmsoVrU5ni32h8izcdrZ44JC3awoHvc6MgP/zp/3oC0C9Ai4Y2HtYpTissEa2ltEpE+rOFy0M5+BJRE X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 75808a37-5b73-46c7-ee4f-08d966f4168c X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Aug 2021 11:41:18.7343 (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: pOe54dQeEsOvsOb86Esh4LBR0+XDs7T/HcEQgRtvD1Sf3DlPo5ea3O1IBGCO/foaXoElUywNY4ZT1iAFIoTCLA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB5696 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org DSA would like to remove the rtnl_lock from its SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE handlers, and the felix driver uses the same MAC table functions as ocelot. This means that the MAC table functions will no longer be implicitly serialized with respect to each other by the rtnl_mutex, we need to add a dedicated lock in ocelot for the non-atomic operations of selecting a MAC table row, reading/writing what we want and polling for completion. Signed-off-by: Vladimir Oltean --- drivers/net/ethernet/mscc/ocelot.c | 53 +++++++++++++++++++++++------- include/soc/mscc/ocelot.h | 3 ++ 2 files changed, 44 insertions(+), 12 deletions(-) diff --git a/drivers/net/ethernet/mscc/ocelot.c b/drivers/net/ethernet/mscc/ocelot.c index c581b955efb3..9f481cf19931 100644 --- a/drivers/net/ethernet/mscc/ocelot.c +++ b/drivers/net/ethernet/mscc/ocelot.c @@ -20,11 +20,13 @@ struct ocelot_mact_entry { enum macaccess_entry_type type; }; +/* Must be called with &ocelot->mact_lock held */ static inline u32 ocelot_mact_read_macaccess(struct ocelot *ocelot) { return ocelot_read(ocelot, ANA_TABLES_MACACCESS); } +/* Must be called with &ocelot->mact_lock held */ static inline int ocelot_mact_wait_for_completion(struct ocelot *ocelot) { u32 val; @@ -36,6 +38,7 @@ static inline int ocelot_mact_wait_for_completion(struct ocelot *ocelot) TABLE_UPDATE_SLEEP_US, TABLE_UPDATE_TIMEOUT_US); } +/* Must be called with &ocelot->mact_lock held */ static void ocelot_mact_select(struct ocelot *ocelot, const unsigned char mac[ETH_ALEN], unsigned int vid) @@ -67,6 +70,7 @@ int ocelot_mact_learn(struct ocelot *ocelot, int port, ANA_TABLES_MACACCESS_ENTRYTYPE(type) | ANA_TABLES_MACACCESS_MAC_TABLE_CMD(MACACCESS_CMD_LEARN); unsigned int mc_ports; + int err; /* Set MAC_CPU_COPY if the CPU port is used by a multicast entry */ if (type == ENTRYTYPE_MACv4) @@ -79,18 +83,28 @@ int ocelot_mact_learn(struct ocelot *ocelot, int port, if (mc_ports & BIT(ocelot->num_phys_ports)) cmd |= ANA_TABLES_MACACCESS_MAC_CPU_COPY; + mutex_lock(&ocelot->mact_lock); + ocelot_mact_select(ocelot, mac, vid); /* Issue a write command */ ocelot_write(ocelot, cmd, ANA_TABLES_MACACCESS); - return ocelot_mact_wait_for_completion(ocelot); + err = ocelot_mact_wait_for_completion(ocelot); + + mutex_unlock(&ocelot->mact_lock); + + return err; } EXPORT_SYMBOL(ocelot_mact_learn); int ocelot_mact_forget(struct ocelot *ocelot, const unsigned char mac[ETH_ALEN], unsigned int vid) { + int err; + + mutex_lock(&ocelot->mact_lock); + ocelot_mact_select(ocelot, mac, vid); /* Issue a forget command */ @@ -98,7 +112,11 @@ int ocelot_mact_forget(struct ocelot *ocelot, ANA_TABLES_MACACCESS_MAC_TABLE_CMD(MACACCESS_CMD_FORGET), ANA_TABLES_MACACCESS); - return ocelot_mact_wait_for_completion(ocelot); + err = ocelot_mact_wait_for_completion(ocelot); + + mutex_unlock(&ocelot->mact_lock); + + return err; } EXPORT_SYMBOL(ocelot_mact_forget); @@ -114,7 +132,9 @@ static void ocelot_mact_init(struct ocelot *ocelot) | ANA_AGENCTRL_LEARN_IGNORE_VLAN, ANA_AGENCTRL); - /* Clear the MAC table */ + /* Clear the MAC table. We are not concurrent with anyone, so + * holding &ocelot->mact_lock is pointless. + */ ocelot_write(ocelot, MACACCESS_CMD_INIT, ANA_TABLES_MACACCESS); } @@ -1028,6 +1048,7 @@ int ocelot_port_fdb_do_dump(const unsigned char *addr, u16 vid, } EXPORT_SYMBOL(ocelot_port_fdb_do_dump); +/* Must be called with &ocelot->mact_lock held */ static int ocelot_mact_read(struct ocelot *ocelot, int port, int row, int col, struct ocelot_mact_entry *entry) { @@ -1078,33 +1099,40 @@ static int ocelot_mact_read(struct ocelot *ocelot, int port, int row, int col, int ocelot_fdb_dump(struct ocelot *ocelot, int port, dsa_fdb_dump_cb_t *cb, void *data) { + int err = 0; int i, j; + /* We could take the lock just around ocelot_mact_read, but doing so + * thousands of times in a row seems rather pointless and inefficient. + */ + mutex_lock(&ocelot->mact_lock); + /* Loop through all the mac tables entries. */ for (i = 0; i < ocelot->num_mact_rows; i++) { for (j = 0; j < 4; j++) { struct ocelot_mact_entry entry; bool is_static; - int ret; - ret = ocelot_mact_read(ocelot, port, i, j, &entry); + err = ocelot_mact_read(ocelot, port, i, j, &entry); /* If the entry is invalid (wrong port, invalid...), * skip it. */ - if (ret == -EINVAL) + if (err == -EINVAL) continue; - else if (ret) - return ret; + else if (err) + break; is_static = (entry.type == ENTRYTYPE_LOCKED); - ret = cb(entry.mac, entry.vid, is_static, data); - if (ret) - return ret; + err = cb(entry.mac, entry.vid, is_static, data); + if (err) + break; } } - return 0; + mutex_unlock(&ocelot->mact_lock); + + return err; } EXPORT_SYMBOL(ocelot_fdb_dump); @@ -2085,6 +2113,7 @@ int ocelot_init(struct ocelot *ocelot) mutex_init(&ocelot->stats_lock); mutex_init(&ocelot->ptp_lock); + mutex_init(&ocelot->mact_lock); spin_lock_init(&ocelot->ptp_clock_lock); snprintf(queue_name, sizeof(queue_name), "%s-stats", dev_name(ocelot->dev)); diff --git a/include/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h index 06706a9fd5b1..682cd058096c 100644 --- a/include/soc/mscc/ocelot.h +++ b/include/soc/mscc/ocelot.h @@ -674,6 +674,9 @@ struct ocelot { struct delayed_work stats_work; struct workqueue_struct *stats_queue; + /* Lock for serializing access to the MAC table */ + struct mutex mact_lock; + struct workqueue_struct *owq; u8 ptp:1; From patchwork Tue Aug 24 11:40:47 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 502180 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, URIBL_BLOCKED, 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 9BEDBC432BE for ; Tue, 24 Aug 2021 11:41:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 84BB9613AB for ; Tue, 24 Aug 2021 11:41:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236910AbhHXLm0 (ORCPT ); Tue, 24 Aug 2021 07:42:26 -0400 Received: from mail-eopbgr80072.outbound.protection.outlook.com ([40.107.8.72]:17383 "EHLO EUR04-VI1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S236805AbhHXLmO (ORCPT ); Tue, 24 Aug 2021 07:42:14 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kvTD5cZlKHA/vC5c0GQrvMDAO9IllX5JgbZ+KjvcX8N3l4BSizHCNKUSHbVTT8wMuPcE4HwqJgNUBbl/zi+s5bKCxeB6sV8PnWo0GGJGIQ/67YLg3VOVIprzbiECe1sRC6xbxGLyY0JI4Y4REwi62eOtQeutDkXiyEXPByXoriKUtfJX6vG0768Q1e2dJTjON6TyItzUro55lq82VOmkVU+sn/t58LXY5OLz4AHdzeIu3hFMJYhy232dn4CSAzolRTBWQezWiXOVmuHKVa1mi52mJnya3VOX3zhJtS8V4ll2rIWkgjdtFhTl4T23EPRMzi6SuYC0dcjeRGXfOFE7SA== 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=uo7LVho/kFD/bfGRA6FWrHB4Us/8LmkEQ8QHsCtz8Cw=; b=aYHR0wrgUkdZoNBEWGeNyXc80m1J8YESymXLpnyXJUEwcCRtZxnGWI9jNHX5dHF8v3I8hSApvwp4C5E940RHa0MxYZNZ/fF/uEp29qqMRl6a43JbzInUIHTzAxVAHssUfxZB7+DTE+nwmo0cFTm9qggwwWKZGO6YS003f0hLC3g7eRm4jgowsR9RFZpzrPHCjsueHBDjTigFKeu93x/dt49TCq0csPpTMnv2oJFIfb0rngNmu0+pkl8z1PLd+8Q7IjlN3EsEtUklEpnD9u+cHwOXciyVzSLXUC3vNTybcOUDWGMCQHqRQOUmCc6uMtRvmsKm0LrTWU7cBePtd77fvA== 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=uo7LVho/kFD/bfGRA6FWrHB4Us/8LmkEQ8QHsCtz8Cw=; b=FRf0gue1ZuMU3IzNy565eSt4vMYaMtc7GTglbCLkM5MklV0LgB+aSm6VmWwv0gMI7SNTVPEUBSLtZSwWjlqgWMb7oJQWk56ikP9cYYRjODS+IZjQOLEZQrkMjBTgPucNwDjuiQHGaew3SsWT5nYBncLPu/Wm/t9LCPEVK9G0eq8= 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 VI1PR04MB5696.eurprd04.prod.outlook.com (2603:10a6:803:e7::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Tue, 24 Aug 2021 11:41:22 +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; Tue, 24 Aug 2021 11:41:22 +0000 From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Florian Fainelli , Andrew Lunn , Vivien Didelot , Vladimir Oltean , UNGLinuxDriver@microchip.com, DENG Qingfang , Kurt Kanzenbach , Hauke Mehrtens , Woojung Huh , Sean Wang , Landen Chao , Alexandre Belloni , George McCollister , John Crispin , Aleksander Jan Bajkowski , Egil Hjelmeland , Oleksij Rempel Subject: [RFC PATCH net-next 6/8] net: dsa: flush switchdev workqueue when leaving the bridge Date: Tue, 24 Aug 2021 14:40:47 +0300 Message-Id: <20210824114049.3814660-7-vladimir.oltean@nxp.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210824114049.3814660-1-vladimir.oltean@nxp.com> References: <20210824114049.3814660-1-vladimir.oltean@nxp.com> X-ClientProxiedBy: FR0P281CA0083.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:1e::18) 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 FR0P281CA0083.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:1e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.6 via Frontend Transport; Tue, 24 Aug 2021 11:41:21 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a225940b-0d0d-4a56-9fdb-08d966f418f7 X-MS-TrafficTypeDiagnostic: VI1PR04MB5696: 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: D8MgFHXJMLLKfwkH80Yg+a5dqRPdPgEAo6u/IrwTvdnebaNSO/Sg9rwmHMIygX56G3xCaCuqZNt5lkBTVmBW+zLc2hNP/XIryhiV9vyrUuorYe6gDjZzhoIvj2GPaOCXQ2K7RqTtmPbCIlx5R2vSpC976p7VEp8GAVNcRQsgTI99Z8ddYdwsZHtEBrSTkLTFvyWTp/9ahipCgRrmxT5JrBr6sRXmfWWB8mGg2lCsyfm+ZDIf5OOB5D+jkI0WGaDs3kwu/1NXhslYCScxiMOEtk3i8fXwPTrLLr8PU39sFV22uPZgTXrJyqswDZhiBvAf6rIfTrywx86C/E2HJ1qinkSH1kCdJKRaXwu5HlDiVxVGIhGSyYwLDyFQUwpQMqUOukZloyJnIQfCGC4FB0oT5xYYoGK9vRifGVBhA9Jo3c0w/eqIC1nPRBL/sfAoc6vh08G2lI3IVxsgRYWp1R2EoGY+SgBbosZC1N8FbLr29KvGAxAHbVfYZVVIPXUwr22zxmhhFAUjPkvlbsC/CcXq3hGhk+z6E5ZglfOLPU7ORFZEm2j2D/nEW4scSXlnDfjtpDRK6GXzRTlkYtDbc3T9jvirFwhKIAj5O71e6+bT1o95XYV9vtb6wTrawe/e2yxMB6xQ0PX4A+6zcU8SmNExjjvQKkkXxD/5Mus+DIdVU9ISXUh6IF7LP6gWOKDtd2gKyT31qdRdxCZsI6vQAH/lNAxQYHT1mta0+xnGvkShtvTG4z90xD+/coUB8ULaVodtkotwRkRziDH5qGD1D7aztA== 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)(366004)(346002)(396003)(136003)(39850400004)(376002)(52116002)(966005)(4326008)(478600001)(5660300002)(6916009)(66476007)(66556008)(26005)(83380400001)(1076003)(36756003)(66946007)(6486002)(6666004)(6512007)(7416002)(6506007)(186003)(8676002)(8936002)(2616005)(86362001)(44832011)(38100700002)(38350700002)(956004)(2906002)(54906003)(316002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: hDySbr6IwGD3RR2FyUZHYgcqOQTQnaQUMdjfaLoUBRUORwesUvlfMuRCrW+gdu9Ukv7LXuA73xTXrf+wamLIelTpbCp9369KUx6UosK0LuICOTSn8OsVITIqXRdTVv4HDfsXQ7Wc6nqPNUx+5Vgtu2ARd5NXWuN48W9fbRKDUQtZPIs/mz8TY3kp8+j4hAzDPvne6QwBv0Di/jICHMjMOTIsmEy2z7mMT6pEieHpjxPtdEWa1lrBVZLeiLSblay/km6mpLUs19mLkc6/fz3xEPcBY+m9VBRAnWuvFED2SU9IUALs6XxtutBjIGmHl9/BmTPU6cJeqZwbWQ1craDVlXLvSrSaAg2hL+xENE3OsvDEe04PL+tgkcNwwsFCsh9un0EzmeSiSU6q9yaCZLAevURj2N2G/0zYOCFfB7zxvZwo8QUf2/FlYhVpk2VHbvhtmlVvJH+5TJ3J5USwCaHPYh3+9XSJfb2yGz6sm/YSTqmueX9QEi1wluUwubApoN+VX+Rl8Jzn1Ti53DkqECHJ2LYH3BHnAz4+TX1SoAneloyNk1KZTlL4ZyZ/yEDsddS4RQ9N061xH53nxqG1UjAz2gqWzQxekat7iYSlOn5Z7YdC7kH1nLvfKV2j8HSY5oLmXGfMtrwHTw//0q9T5IQMk9RSyQBjYEpwlunTINSPAq1Kx4QcnEaoAF9nuYhITpL5whdfNnXxvo7mmnVGzpInKkZudzbjV8/uEGKpD/moQ1oeJHGTu8uaBpdShgB6B79OjkgTmEGE8MnqqkOcOvJnBFWOp9/EpYm68997qmHucSFPK4CWq2zo5VSnKu7651KtpogP2w4LNpd9+BJU0TpgDNFbFUIIkvJAaWxOLVaIUXyglY8oh5KrNM9sCJN1gyl6kwIljkkjjOPxmLHNXUvFWQYLqkoioPtePZanAkxvHSVcQe/FcrTjnhee+SfDfSx6rZH1naV08WBMu7CnWfZ6yoSnYcV/sY6aCFTr2UvSGirpg9LwRLHiAyFbsDSZqVA/zsAS988vdeTsHkebrHvtcTyqvZaTN/Y0qQZn6YdRz6hhU+ovIywsKexE9tKF0QTozsuZh7AIW1gs7ti3UY+RyP1rGRDmtyhSokTM+jwt0zjbGlT62+dWrSOCevz1FS2o+C/8spzVamuB+cYL0YS39hsplNmTzmX+2+s9U3jqH3F3T6QwMuzhucj0UA28cmZBrGwxEUIWrSMIcAaFxndCLuhXMhv3fRSqOdv8U0CPtKYuTTpvmYj1c3AzZTbF6pgQpe7qSfQmeEaLaNI0IszKP+n1iMaI3OWhhwd0wEa3WeZnwSDyV83Tns+yQl+gZ+Nn X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: a225940b-0d0d-4a56-9fdb-08d966f418f7 X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Aug 2021 11:41:22.8179 (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: 9Xq92tuHw4qCTver4AnC/qAtem2YqeWG8ZjTpXc22hRyhJL35LJ6Ja+X78OawygQ+qA6GRasjv+XZ5bp8wuSAw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB5696 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org DSA is preparing to offer switch drivers an API through which they can associate each FDB entry with a struct net_device *bridge_dev. This can be used to perform FDB isolation (the FDB lookup performed on the ingress of a standalone, or bridged port, should not find an FDB entry that is present in the FDB of another bridge). In preparation of that work, DSA needs to ensure that by the time we call the switch .port_fdb_add and .port_fdb_del methods, the dp->bridge_dev pointer is still valid, i.e. the port is still a bridge port. Currently this is true for .port_fdb_add, but not guaranteed to be true for .port_fdb_del. This is because the SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE API requires drivers that must have sleepable context to handle those events to schedule the deferred work themselves. DSA does this through the dsa_owq. It can happen that a port leaves a bridge, del_nbp() flushes the FDB on that port, SWITCHDEV_FDB_DEL_TO_DEVICE is notified in atomic context, DSA schedules its deferred work, but del_nbp() finishes unlinking the bridge as a master from the port before DSA's deferred work is run. Fundamentally, the port must not be unlinked from the bridge until all FDB deletion deferred work items have been flushed. The bridge must wait for the completion of these hardware accesses. I have tried to address this issue centrally in switchdev by making SWITCHDEV_FDB_DEL_TO_DEVICE deferred (=> blocking) at the switchdev level, which would offer implicit synchronization with del_nbp: https://patchwork.kernel.org/project/netdevbpf/cover/20210820115746.3701811-1-vladimir.oltean@nxp.com/ but it seems that any attempt to modify switchdev's behavior and make the events blocking there would introduce undesirable side effects in other switchdev consumers. The most undesirable behavior seems to be that switchdev_deferred_process_work() takes the rtnl_mutex itself, which would be worse off than having the rtnl_mutex taken individually from drivers which is what we have now. So to offer the needed guarantee to DSA switch drivers, I have come up with a compromise solution that does not require switchdev rework: we already have a hook at the last moment in time when the bridge is still an upper of ours: the NETDEV_PRECHANGEUPPER handler. We can flush the dsa_owq manually from there, which makes all FDB deletions synchronous. Major problem: the NETDEV_PRECHANGEUPPER event runs with rtnl_mutex held, so flushing dsa_owq would deadlock if dsa_slave_switchdev_event_work would take the rtnl_mutex too. So not only would it be desirable to drop the rtnl_lock from DSA, it is actually mandatory to do so. This change requires ACKs from driver maintainers, since we expose switches to a method which is now unlocked and can trigger concurrency issue in the access to hardware. I've eyeballed the existing drivers, and have needed to patch sja1105 and felix/ocelot. I am also looking at the b53 driver where the ARL ops are unlocked. The other drivers do seem to have a mutex of sorts, but I am fairly skeptical that its serialization features have really been put to the test (knowing that the rtnl_mutex serialized accesses already). So any regression test from drivers that implement: - .port_fdb_add - .port_fdb_del - .port_fdb_dump - .port_mdb_add - .port_mdb_del - .port_fast_age is appreciated. Signed-off-by: Vladimir Oltean --- net/dsa/dsa.c | 5 +++++ net/dsa/dsa_priv.h | 2 ++ net/dsa/port.c | 2 ++ 3 files changed, 9 insertions(+) diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c index 1dc45e40f961..8e7207c85d61 100644 --- a/net/dsa/dsa.c +++ b/net/dsa/dsa.c @@ -345,6 +345,11 @@ bool dsa_schedule_work(struct work_struct *work) return queue_work(dsa_owq, work); } +void dsa_flush_work(void) +{ + flush_workqueue(dsa_owq); +} + int dsa_devlink_param_get(struct devlink *dl, u32 id, struct devlink_param_gset_ctx *ctx) { diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h index 33ab7d7af9eb..1dc28ad4b8a8 100644 --- a/net/dsa/dsa_priv.h +++ b/net/dsa/dsa_priv.h @@ -170,6 +170,8 @@ void dsa_tag_driver_put(const struct dsa_device_ops *ops); const struct dsa_device_ops *dsa_find_tagger_by_name(const char *buf); bool dsa_schedule_work(struct work_struct *work); +void dsa_flush_work(void); + const char *dsa_tag_protocol_to_str(const struct dsa_device_ops *ops); static inline int dsa_tag_protocol_overhead(const struct dsa_device_ops *ops) diff --git a/net/dsa/port.c b/net/dsa/port.c index 616330a16d31..65ce114b9fc8 100644 --- a/net/dsa/port.c +++ b/net/dsa/port.c @@ -380,6 +380,8 @@ void dsa_port_pre_bridge_leave(struct dsa_port *dp, struct net_device *br) switchdev_bridge_port_unoffload(brport_dev, dp, &dsa_slave_switchdev_notifier, &dsa_slave_switchdev_blocking_notifier); + + dsa_flush_work(); } void dsa_port_bridge_leave(struct dsa_port *dp, struct net_device *br) From patchwork Tue Aug 24 11:40:49 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 502182 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, URIBL_BLOCKED, 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 E7C4DC432BE for ; Tue, 24 Aug 2021 11:41:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CFB08613BD for ; Tue, 24 Aug 2021 11:41:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236885AbhHXLmU (ORCPT ); Tue, 24 Aug 2021 07:42:20 -0400 Received: from mail-eopbgr140059.outbound.protection.outlook.com ([40.107.14.59]:35148 "EHLO EUR01-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S236781AbhHXLmL (ORCPT ); Tue, 24 Aug 2021 07:42:11 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GM6bGaEniJNC80CPdZm3xVhwteVHbs5RGv4v7y0cTeSw18wA5qSxFBDYTwqA1uEZ36S9Sl5gEace43LrUJxbhzKwaVFy3bEbwrOyN+y3RxQGCsc6W+TTbNv+zrVlgRL9HyHls4r9ogTgXX25Tg5lXWPaHtNdTKEiQgGKtsA6yh7SPb1U91+3i0ktWD7GB6qsqiJGHUXPMHJbE5CRQfm9zli1GTkP8r62krLGtxhv8K4bdOF3FCNX7sMQo1I5Q26ifeiBNry29St9j3oUc1HT++85jiYkTKFP/u6cS6S+Cs/uYtsODFlmICWm8xik2fWY5IDPVYLCuMJuP9L6nxaJhg== 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=6zYHwQs9eClKuTbenfncX6ggQq2V/kVMCgpGj+9AXqI=; b=HMcGvtk8wr7mT21G/AFr32CDOygcbm+ouRd6vKGnB0zfllt7ResQU81N8BJdVwYTPutEi/UBtG5UhrIuYetROEVvg811cHTBxtQykvTOPF152uXGNBImQf4y4ccLBCE8/o2A9lf8xJX8G9H4tC+bmnflurKZ4D2tJ9+XM5wUdCmWiiBLVXc6Q/TdxErFMwNYXFWUiJwbmM9/cOxbYCjujifWqmYR+DmUbtWoITOBzaAohS7feO+Dr4qQH+iwZ/GcVbGELNl+HV/lgzmWyOScXSOwE6cjq/W4d7CmCHUgzZ2N7o9E8kE8u2S9zHgLWlxAtTPu5IBa4E0Qkigp/+EkSQ== 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=6zYHwQs9eClKuTbenfncX6ggQq2V/kVMCgpGj+9AXqI=; b=gxhkq3ux8ResW6VvTkkuiFpXvHDOFrJzMbb8bMIi2c6oTKjjQvSl2SZYqxCeagLOVPYjNxYSrhUQiZqHLp18Deljmd2fqlN5CSQFKOBQC2093fNESpn1wsi7E1Cou4NHuNv7f6uH7Ab3IeYcgC5dJdchAx6ARqlOL9IT/w9OgKg= 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 VI1PR04MB3070.eurprd04.prod.outlook.com (2603:10a6:802:4::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.22; Tue, 24 Aug 2021 11:41:25 +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; Tue, 24 Aug 2021 11:41:25 +0000 From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Florian Fainelli , Andrew Lunn , Vivien Didelot , Vladimir Oltean , UNGLinuxDriver@microchip.com, DENG Qingfang , Kurt Kanzenbach , Hauke Mehrtens , Woojung Huh , Sean Wang , Landen Chao , Alexandre Belloni , George McCollister , John Crispin , Aleksander Jan Bajkowski , Egil Hjelmeland , Oleksij Rempel Subject: [RFC PATCH net-next 8/8] selftests: net: dsa: add a stress test for unlocked FDB operations Date: Tue, 24 Aug 2021 14:40:49 +0300 Message-Id: <20210824114049.3814660-9-vladimir.oltean@nxp.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210824114049.3814660-1-vladimir.oltean@nxp.com> References: <20210824114049.3814660-1-vladimir.oltean@nxp.com> X-ClientProxiedBy: FR0P281CA0083.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:1e::18) 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 FR0P281CA0083.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:1e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.6 via Frontend Transport; Tue, 24 Aug 2021 11:41:24 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 238e44d3-ff3e-40ee-ef72-08d966f41a90 X-MS-TrafficTypeDiagnostic: VI1PR04MB3070: 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: VQMz4I+ufN2EqdEavoGF84kxYXgmbJeLRdYpE2uuoHdw8vjcOKGF9X4nqre6XXbrKM0lMwEVrX6tc5WYM8Dv+SWAut2X6mwhi+cDDFBioGqzWtLufZL9Lip4M9W6d8ADE98LB9hJWik4R4javh3fP1dcq81A4zUPVJFLp2FXWthgoNwIXuDf3J57cShhsgrL6EAEseIX6zzncYF8X1uAmvKdYV9zlgWzPiYqN7CGiMC5AOXFq3d+UqPmx49rbv1/viYPKBZmjPBft8b9YnKMSDnwK+lmSbGMLWKOm5UTkjtlNfqCvtCgF6rrCwV95UZX1WODa/HhZFPFzcriiyBwb+qJUL2y11s9hpvSLihsmw76UVdeYbSwivJ7U1usdHhv8daafwzeXFhBxzrXqOvy1qeKetZnO7wXdFKtDjO9Dp/dq6xqESwUuoUwJ1ccVhAnWbPhWUJ4jIa4HR/9PkdmEv1bjwoTx0F7bqgdis8zgyyr/heFbDnVRdpfOtb4n8gaVJxYkE75CcclrbYs/zbDtUhwx8YYs+TJ7gsuc7Tn0+nIiDEY4iKYpSPy/f+RbZgJ5AzFvbD6IQf697stwyAfwz6OlKNm9mdANUt2iYUpnJXFvpl2eucN0sWURtjALbuTXEsnamPuEhKePQKPhnY4DwGnyONO9csqJtkXX6Xi/ZwT5/a1eEznESmmPdwezyZb/ejWGBgvbYa9JigJqgQPnQ== 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)(346002)(376002)(366004)(396003)(39850400004)(136003)(6486002)(8676002)(66556008)(66946007)(186003)(5660300002)(66476007)(6512007)(4326008)(86362001)(1076003)(956004)(36756003)(26005)(2616005)(6916009)(316002)(6506007)(52116002)(44832011)(8936002)(478600001)(6666004)(38350700002)(38100700002)(83380400001)(54906003)(7416002)(2906002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: dvBR75Kp6m/qTlaiNBMFxeYf+XvbV9oo3x2yamF0Da4fx0NT5MlYhEWcX977Ixur48kuG+e4uCdeJTBv/vQ2M0i8wenuu+3ILkoUVmwqUV3DRg6BGGcTNvdzIWc/9nFHCOqNhsRsW9Q/IlYMnO3N4TYXO84etihp4WTwYzwi2xUY9EAMtShMPt9uWYBwAbCCmTYRZlsNbDzk2aVAm+3XT+AySFaOc/GQj7JSjX5rxe0Iuk9xjE6ekwHLC3XsGw0KkH3yH9BTqDJhHIArDUzRJcHH5mvZ+Zz2TR+zm490fjvdOrn/uPIEL6aRA+lgfasJSuBDiMHCn5sWwQO20uRqgNQw6XojK4nBKzTy4ND7F0FZIt2FbQoVy2y8hCMDfO1hO81tvfYXxkkkKNnXstYE+4J6/JK9HHbkcaV+fE/C9YQ5H5qol9/4ar7qBb46Cu+PjTikaAf+EkOtWL/wdLHWqV66J8fgtZddFp8eNdtS1hqW1kFFDnBLZFQ6DgqqjHJd1ebrvTwD9qqXkVBvRQbXYoO+vue/bFvgQ1IiPewWmA7m2584tTQlNusa6Ko16LAv9lw4NKBQVxqc4BHxgZgyK+39RmyoiTVw/lsaQNLA60gCM/Xgyog78vCeLlVbAyIRaKPrQ2cE1uT/ll5T+/yDO1z+TCCzBKQY3bwoFTELQRugCvydVdAdg5xqDrvBbbxrZOAASKeKDK5oPjL7F6jEmiS1OxM1hXo5i2wVEbyG8WeS6urJqC08Hh5bWmW9MOmzsfNnCpUMB9VRJNgGXJyyuGSf2MZnAtEp5+WEOey0IPvF0hkyLZPV54UI/xP16vNUEbjEelZbx3kKjnlnxqr/2bv6G4EypendTyXIBnI/r9w/+BN5wi2bsr7q0OTrQ7HVWuzmvfgODSjUYjdhbSuWXESnfligO/ZiSi8RpkO1SD2Mu/GpfHK1LoQAOuxd8GE1AEUXOSSRIgRLx0+THAAcIBSypX51k/vBX6C1mR5lVkPKzeEnsLtPL5N2ISTZdBGw6eGqOZUDSKi2bWrhQ03TNZVHZE9ZRQ3d3JqMQfouOMQnWEbsLIhrD7qMql8NTLe4w9cV0cpB+h3m8DLoLw6dohD6i8oaY9dMDgDhuNPf3jv7mwirg+D7j9VgFp2oPVu6+lRCgjjc3M1LgSWE9a/hw2gfS5MA2vIsWW/f4ibMUSc8YmR7FvNcycjimtOORwHBEm+Euany9FQvLsMSjTEzLCjS2vQmYtWfM2Z9/SASNTvZ6CkakhnFtg/n9t0fNYitb5bSGqafjYvXfU75EMq2vYMm7DVJK/VN0OSVwgxEfZuSRaBfqyklz6j+Dmb9QPPr X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 238e44d3-ff3e-40ee-ef72-08d966f41a90 X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Aug 2021 11:41:25.5074 (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: UFAhKNqir5GbWvXaElLH0X7idTjRKegVLtptd8wzfXz8zqMfQpx9qQqYwPUmb5bqkbX5aaKBq3VsUKrgUbK4Qw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB3070 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org This test is a bit strange in that it is perhaps more manual than others: it does not transmit a clear OK/FAIL verdict, because user space does not have synchronous feedback from the kernel. If a hardware access fails, it is in deferred context. Nonetheless, on sja1105 I have used it successfully to find and solve a concurrency issue, so it can be used as a starting point for other driver maintainers too. Signed-off-by: Vladimir Oltean --- MAINTAINERS | 1 + .../drivers/net/dsa/test_bridge_fdb_stress.sh | 48 +++++++++++++++++++ 2 files changed, 49 insertions(+) create mode 100755 tools/testing/selftests/drivers/net/dsa/test_bridge_fdb_stress.sh diff --git a/MAINTAINERS b/MAINTAINERS index 06e39d3eba93..23b65ef5f11a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12958,6 +12958,7 @@ F: include/linux/dsa/ F: include/linux/platform_data/dsa.h F: include/net/dsa.h F: net/dsa/ +F: tools/testing/selftests/drivers/net/dsa/ NETWORKING [GENERAL] M: "David S. Miller" diff --git a/tools/testing/selftests/drivers/net/dsa/test_bridge_fdb_stress.sh b/tools/testing/selftests/drivers/net/dsa/test_bridge_fdb_stress.sh new file mode 100755 index 000000000000..cdb7f9ca2251 --- /dev/null +++ b/tools/testing/selftests/drivers/net/dsa/test_bridge_fdb_stress.sh @@ -0,0 +1,48 @@ +#!/bin/bash +# SPDX-License-Identifier: GPL-2.0 + +# Bridge FDB entries can be offloaded to DSA switches without holding the +# rtnl_mutex. Traditionally this mutex has conferred drivers implicit +# serialization, which means their code paths are not well tested in the +# presence of concurrency. +# This test creates a background task that stresses the FDB by adding and +# deleting an entry many times in a row without the rtnl_mutex held. +# It then tests the driver resistance to concurrency by calling .ndo_fdb_dump +# (with rtnl_mutex held) from a foreground task. +# Since either the FDB dump or the additions/removals can fail, but the +# additions and removals are performed in deferred as opposed to process +# context, we cannot simply check for user space error codes. + +WAIT_TIME=1 +NUM_NETIFS=1 +REQUIRE_JQ="no" +REQUIRE_MZ="no" +NETIF_CREATE="no" +lib_dir=$(dirname $0)/../../../net/forwarding +source $lib_dir/lib.sh + +cleanup() { + echo "Cleaning up" + ip link del br0 + kill $pid + killall bash + echo "Please check kernel log for errors" +} +trap 'cleanup' EXIT + +eth=${NETIFS[p1]} + +ip link del br0 2&>1 >/dev/null || : +ip link add br0 type bridge && ip link set $eth master br0 + +(while :; do + bridge fdb add 00:01:02:03:04:05 dev $eth master static + bridge fdb del 00:01:02:03:04:05 dev $eth master static +done) & +pid=$! + +for i in $(seq 1 50); do + bridge fdb show > /dev/null + sleep 3 + echo "$((${i} * 2))% complete..." +done