From patchwork Mon Sep 20 21:42:08 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 12506443 X-Patchwork-Delegate: kuba@kernel.org 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=unavailable 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 37FE6C433EF for ; Mon, 20 Sep 2021 21:45:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0AADF6121D for ; Mon, 20 Sep 2021 21:45:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238915AbhITVqp (ORCPT ); Mon, 20 Sep 2021 17:46:45 -0400 Received: from mail-eopbgr70059.outbound.protection.outlook.com ([40.107.7.59]:57732 "EHLO EUR04-HE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S242319AbhITVon (ORCPT ); Mon, 20 Sep 2021 17:44:43 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zpvleg64dsmr3vwPG/BMPx+tjHP4VZekxtdUSGyswXcakg79q8hKV7eLs/6OKMnXHerRNHhPzgBNte7rv1FdNft3Yf44zy6Zu47eo33cweF8LFcq4XTD8RWyuXQVrj0d7ZR2XdjKl1G8WLBYzXHU6gsFWF+DBMaPJGibsHXb1lhTgqEy/AYl6g9xdvkNOlovE6s69jpKUov1GzxE2rjAktfDOFmw6RKFfGs3sDSdZVn3YpPy3S6nu82DGd8TCtmdL3/aFvFyM00Qzv58IV9IVo9NGO00E5Db5oeQ1qifbE7ax7483xWuIq9HyrdIJPDL3+5bdaTgyA62owyGAZ+nXA== 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; bh=aEnsN31ODS8Y5+Y9sQH9j/D93dSyuz9jU8xo90+KYSo=; b=T/lluOa/PanIKDlMRa8zqj38eQwYBkB0Bz+RNWUjVLvlqNET+bRl4unaUC3ZrEDv3vNbdh1iYjoFnW7OPOCTELa+s/3CbDTGfiyjWMe02rE8tj1RMBpnA73FxHZJXrQwQ69zNSLvvPjXot5WzP9JBItod2gVFTaTPNeY5uflrB2O+hieeqMHZivkYfzPr+0siCGAvZyCVtg3S6yqE1amsc1kcmGLSOSUPpMwpMCG1IVTdkOa5bRbXgevwG0dJ90Uf0inEuU7Vjq9EJ5A6ILIPzma4URsHEVbaMc1EU9ndVWuIJdavDH04Xh+WYwoVafFv6PHVzbR8/oXdYTjBOPDmg== 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=aEnsN31ODS8Y5+Y9sQH9j/D93dSyuz9jU8xo90+KYSo=; b=XPTWrj3hH9yi+Civ9LTUy5OYohvbuvi7PbFtlHY+K5X63agLQJ1yjY3KaK5rxFgCQh/ECyjeW9RbTmzj8m1LwZiodxsfs9uIeg/UzwGmG/Jaef937vCbkkpQ8g75OpuyxL3rz8E9SK7/v3NEf9w3FAwrB8Eu4SJM5pRk8EQc6eM= 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 VI1PR04MB3198.eurprd04.prod.outlook.com (2603:10a6:802:9::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.14; Mon, 20 Sep 2021 21:42:41 +0000 Received: from VI1PR04MB5136.eurprd04.prod.outlook.com ([fe80::e157:3280:7bc3:18c4]) by VI1PR04MB5136.eurprd04.prod.outlook.com ([fe80::e157:3280:7bc3:18c4%5]) with mapi id 15.20.4523.018; Mon, 20 Sep 2021 21:42:41 +0000 From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Linus Walleij , Andrew Lunn , Vivien Didelot , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Jakub Kicinski , Bartosz Golaszewski , Wolfram Sang , linux-i2c@vger.kernel.org, Mark Brown , linux-spi@vger.kernel.org, =?utf-8?q?Alvin?= =?utf-8?q?_=C5=A0ipraga?= , Lino Sanfilippo Subject: [PATCH net 1/2] net: dsa: don't allocate the slave_mii_bus using devres Date: Tue, 21 Sep 2021 00:42:08 +0300 Message-Id: <20210920214209.1733768-2-vladimir.oltean@nxp.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210920214209.1733768-1-vladimir.oltean@nxp.com> References: <20210920214209.1733768-1-vladimir.oltean@nxp.com> X-ClientProxiedBy: AM0PR04CA0092.eurprd04.prod.outlook.com (2603:10a6:208:be::33) To VI1PR04MB5136.eurprd04.prod.outlook.com (2603:10a6:803:55::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost.localdomain (82.78.148.104) by AM0PR04CA0092.eurprd04.prod.outlook.com (2603:10a6:208:be::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.16 via Frontend Transport; Mon, 20 Sep 2021 21:42:39 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7595772f-893e-4316-120f-08d97c7f9268 X-MS-TrafficTypeDiagnostic: VI1PR04MB3198: 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: ZU2rv9AqpWCMkAguox8oVUv9OpnUEGTAvWmZplbexX1a+NQZgpBgldsyDZiqxhMfSXpT/COrKv/84f0H4wXYaLnkK581XoDTxdPtPVE1U6YzfjXccADdm6PCcXGx43e+fm5KJUhfj7NtINDAYY7HXWDza+hRo3YuZ2ZQUFMTZZG46rug3Nqzkrh8HChPgc/M0Fuk/edbDgcF9bqjTxHN5Y8sVJsAqiKBV9tBaZ67nM5puwJAWe8COEZJHQt49AcxUVilNy5UG6/V/M/Hb4+Jya11YCncZ1T6raktxERY2ztgPiMNYSr+U1SKNOZASVNvYHkaQKqaYQvwLkSCvf2se1vniUWFmgZJKoKb47Xvy5Tg+jmY1fiB5HEWpIF/imo872xZiudKvcJY0lyHMa0PpacuVvutOrvJOopuq8J14ZjLvC7BtmtF8cLcdXSHKIdMK9zvLDgVnY9MuYlQNXgmk8M4DCaovpUDtoA8pSIepi2POWxhjg80QXJfKz9XEx64U+vKJA7OsNu+wXg9uIrv50+jDyhja4oGfbLj1ux8DF64/zHMDBsHqfD3okabyGhwXUZaVxllwhQ/S4NYa/m0m9gwqAvGj1Z3Cw35weH1def+qEYFPotlqVRndjsLn8GEqwbMgVzc73k1VQV2E4eZij1VzW7DR69G68ToPMSB3w/RxZorOT75mFpX1fvMbVWpMBU0GAnqcfgbajuQjLK8ag== 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)(366004)(396003)(376002)(39860400002)(136003)(52116002)(38100700002)(38350700002)(4326008)(1076003)(44832011)(7416002)(83380400001)(66946007)(26005)(6486002)(8936002)(2616005)(8676002)(6512007)(6916009)(956004)(2906002)(478600001)(66476007)(66556008)(316002)(54906003)(36756003)(186003)(86362001)(6506007)(5660300002)(6666004);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 4OvVWCnjrR9hQuNACZgcireChPmXy214Ht2sFOTdGwCPSBlR8KXMG3OiYOlsLF190Nv80knYHBX2TmY1ee7+WnSuDA/kPUCnZJXKESxsULMxtcpSh0Ph+YO2HkivoUcVzdcLwOp2qV69N7Ds8riGnr7f/D8vm3vJ98NzeP+QuhM4O+wewUG6I7OIF9DX/FbyfyAkNlv8ceOG2CQDqKsISUgPignIvheJQ95ehlLRqoX0bYzpvCgqiKyej4ahy2yeJ4/PH48Pz/hDV+jLSJLJLWflcUlZd9Mx6uTOs9efgL/qA1gLUf8cGZrkCeLNRPHrdDVuK08i7BlDNqcFzbHaG9TCwfpKQdl1ZzjklkNlouGWG8UQUNAeUbuj1Ud1+Z0Htd+KunZnFeFhNvySW0qCNdt4ycfle392a8teScgJxx4mnq2KumcePFOA6yX338FCakDjUmK/fvRcQHSTUQDzC0i2ReXl3r9xRfwcL6+gxqsGpKvYWFPo7Pk7HyNMTvWzUFsEnPmJNwV7I5aNVKPlf6puB3lBygxNHlNygigW97ukO+dYU/J5QAD9Lp2WN6/Zz5axngTWiWG+h5avwi2GGO9rR797UoMd5LqjH5QPXnJ4VCFXSLdMWj1H4ReHJwiDUvDM5Txy1AyUuO5PlBUCiOOyVyd+IsCs9Jd3tMAmWXz44bRtGds1Z372gzxIFoUD6fOijiLvw3rJUXquY7p+PQHvAtF+BGaVAvHOu8lN7gleOBtzQB9mN/prU2l6Cpq4iUAJGuZZ8+jqq40Hlv0WnEdXUL+Aky+V3sSyuaSfVXnSOx9zIa61n1Yb1xfufTfdgk3PxDPfbVOdExUUGeRj2S5Y0pfNmkhm89swGCU4YWs9COrzUWBRScdy7P5GpPSoq5/pvsiY7JXFfEmCVMXu54UJzxsrpFxIc50bLvU03vUZm4iYQ+t5T7IKAAOwvPjpksvjYLYNagAHFWmCGiDZnTEbUV8B22yXOpfu99erJ1Z2Hjy6wfrSKF9xkMVfeIEkZfx50FsMSk1YuDo/k+9DonB513Rflxfn9kFXgrNH3MN5r30DuvlmpDvKHK5CnnxtGkMoJb2sY6Qqs52LhP3N25bRFJT9K1hOxN2FuC1FvrB+0HKdwFjRygBkn/4V7iSCNIu59Va3b1iXIaPEO8wBraFC2MHOLihY+GbQXzGGw/WJkUsBSgzg4R9Igb8/V3yMMUexKUbii91LkeHXX86kQm4XNQHrYbX9GuQshzhQzwwfVkP51U77LOcsmq78KS5ChnJc0Hv5SZOOzip13jsfiKWJqLMAPAm3a6tdFfUCS7fqatiUSaEKWLM2U7jNocQd X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7595772f-893e-4316-120f-08d97c7f9268 X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2021 21:42:41.0379 (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: GZ599JOZ1VeJY7cL7dYxz9ukJbghxs8NV9a8RF1BbGfLjamWAxzBNesVDugyvBx9bCe9l83beq344oqKWepoHg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB3198 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org The Linux device model permits both the ->shutdown and ->remove driver methods to get called during a shutdown procedure. Example: a DSA switch which sits on an SPI bus, and the SPI bus driver calls this on its ->shutdown method: spi_unregister_controller -> device_for_each_child(&ctlr->dev, NULL, __unregister); -> spi_unregister_device(to_spi_device(dev)); -> device_del(&spi->dev); So this is a simple pattern which can theoretically appear on any bus, although the only other buses on which I've been able to find it are I2C: i2c_del_adapter -> device_for_each_child(&adap->dev, NULL, __unregister_client); -> i2c_unregister_device(client); -> device_unregister(&client->dev); The implication of this pattern is that devices on these buses can be unregistered after having been shut down. The drivers for these devices might choose to return early either from ->remove or ->shutdown if the other callback has already run once, and they might choose that the ->shutdown method should only perform a subset of the teardown done by ->remove (to avoid unnecessary delays when rebooting). So in other words, the device driver may choose on ->remove to not do anything (therefore to not unregister an MDIO bus it has registered on ->probe), because this ->remove is actually triggered by the device_shutdown path, and its ->shutdown method has already run and done the minimally required cleanup. This used to be fine until the blamed commit, but now, the following BUG_ON triggers: void mdiobus_free(struct mii_bus *bus) { /* For compatibility with error handling in drivers. */ if (bus->state == MDIOBUS_ALLOCATED) { kfree(bus); return; } BUG_ON(bus->state != MDIOBUS_UNREGISTERED); bus->state = MDIOBUS_RELEASED; put_device(&bus->dev); } In other words, there is an attempt to free an MDIO bus which was not unregistered. The attempt to free it comes from the devres release callbacks of the SPI device, which are executed after the device is unregistered. I'm not saying that the fact that MDIO buses allocated using devres would automatically get unregistered wasn't strange. I'm just saying that the commit didn't care about auditing existing call paths in the kernel, and now, the following code sequences are potentially buggy: (a) devm_mdiobus_alloc followed by plain mdiobus_register, for a device located on a bus that unregisters its children on shutdown. After the blamed patch, either both the alloc and the register should use devres, or none should. (b) devm_mdiobus_alloc followed by plain mdiobus_register, and then no mdiobus_unregister at all in the remove path. After the blamed patch, nobody unregisters the MDIO bus anymore, so this is even more buggy than the previous case which needs a specific bus configuration to be seen, this one is an unconditional bug. In this case, DSA falls into category (a), it tries to be helpful and registers an MDIO bus on behalf of the switch, which might be on such a bus. I've no idea why it does it under devres. It does this on probe: if (!ds->slave_mii_bus && ds->ops->phy_read) alloc and register mdio bus and this on remove: if (ds->slave_mii_bus && ds->ops->phy_read) unregister mdio bus I _could_ imagine using devres because the condition used on remove is different than the condition used on probe. So strictly speaking, DSA cannot determine whether the ds->slave_mii_bus it sees on remove is the ds->slave_mii_bus that _it_ has allocated on probe. Using devres would have solved that problem. But nonetheless, the existing code already proceeds to unregister the MDIO bus, even though it might be unregistering an MDIO bus it has never registered. So I can only guess that no driver that implements ds->ops->phy_read also allocates and registers ds->slave_mii_bus itself. So in that case, if unregistering is fine, freeing must be fine too. Stop using devres and free the MDIO bus manually. This will make devres stop attempting to free a still registered MDIO bus on ->shutdown. Fixes: ac3a68d56651 ("net: phy: don't abuse devres in devm_mdiobus_register()") Reported-by: Lino Sanfilippo Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Tested-by: Lino Sanfilippo Reviewed-by: Andrew Lunn --- net/dsa/dsa2.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c index f14897d9b31d..274018e9171c 100644 --- a/net/dsa/dsa2.c +++ b/net/dsa/dsa2.c @@ -880,7 +880,7 @@ static int dsa_switch_setup(struct dsa_switch *ds) devlink_params_publish(ds->devlink); if (!ds->slave_mii_bus && ds->ops->phy_read) { - ds->slave_mii_bus = devm_mdiobus_alloc(ds->dev); + ds->slave_mii_bus = mdiobus_alloc(); if (!ds->slave_mii_bus) { err = -ENOMEM; goto teardown; @@ -890,13 +890,16 @@ static int dsa_switch_setup(struct dsa_switch *ds) err = mdiobus_register(ds->slave_mii_bus); if (err < 0) - goto teardown; + goto free_slave_mii_bus; } ds->setup = true; return 0; +free_slave_mii_bus: + if (ds->slave_mii_bus && ds->ops->phy_read) + mdiobus_free(ds->slave_mii_bus); teardown: if (ds->ops->teardown) ds->ops->teardown(ds); @@ -921,8 +924,11 @@ static void dsa_switch_teardown(struct dsa_switch *ds) if (!ds->setup) return; - if (ds->slave_mii_bus && ds->ops->phy_read) + if (ds->slave_mii_bus && ds->ops->phy_read) { mdiobus_unregister(ds->slave_mii_bus); + mdiobus_free(ds->slave_mii_bus); + ds->slave_mii_bus = NULL; + } dsa_switch_unregister_notifier(ds); From patchwork Mon Sep 20 21:42:09 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 12506445 X-Patchwork-Delegate: kuba@kernel.org 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=unavailable 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 14536C433FE for ; Mon, 20 Sep 2021 21:45:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EF58C6121E for ; Mon, 20 Sep 2021 21:45:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237294AbhITVrO (ORCPT ); Mon, 20 Sep 2021 17:47:14 -0400 Received: from mail-eopbgr70059.outbound.protection.outlook.com ([40.107.7.59]:41110 "EHLO EUR04-HE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S245186AbhITVpN (ORCPT ); Mon, 20 Sep 2021 17:45:13 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SKI6k7A43jGUgQgxqe4yLE4sBdRsKR3bzzKEr+5R+LbtHRufnntgzH42EA5n9SPJRau+doDoaNgc7sRcnchlANz650zE7BuwL6pglMLmTsvNc7UfG0WcMKvFyl+1OzPYaj4aeVrnDX9SIZUy5KgwtHCFbSBaqBW4wHl45uepWG9lUDpghnj5q7tItebzjAfvKfhFVY59tJGdlvFfWiOo+deTYcgwJgUQL7U9GrA1yzauH6eVtlDiVrR9U0FXTx8I1TpfL1GzvsPBfVVGUy8z0s/RFUd8JUATK1Fdno98NVRXjf+zOgWawlu+vsJcZdSD2rs63iNQ6htr7qiNHhfcSA== 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; bh=TzJNXqhszzFJbBvFD8Atx4FK+G4wrReHxStOnJFKFU4=; b=L9tDJVUjxET2pbEN4WYo74cULT7Z+cX15CINPcZV3DUChihLKtURQIRE+px885SCaxwQIjX6cN8lTm6O5j4f2z6/nKpZbtNEW1YuvjIEsz1D1YpIW9Q7CF86mivm0iSGmauFaAHQh3sYrcN6RoB6ud4sZHYDjoGCZf7fi6JqgIoEnyzIzXfVXI1BKyVJPYIzUkk8GebCSkr4XcQqzize2lXaek5+4hsu+IqXHFGE7JwWst/irtFMhdjcQ1ycaN27dbFvHvzBF12HHpz9ChN6SddW4P4U0RPo9oKHIUg29c/P1NvqUqizV6CgJNKnnE25UQXh/libpg5/LoZisrDdBQ== 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=TzJNXqhszzFJbBvFD8Atx4FK+G4wrReHxStOnJFKFU4=; b=PDmiPLTArRABu7ex4tbhQQhdIpJYFOL1P5srAOhWgMv3phdOvfHNGB8jufYxkRUT4n90DsrwcuUPLXNvAA34ZW/M86cFgi3V5pGFG6wiszVNM5dMPuHfrpYAkSubeqQWHbksDHRaI3y7K4IbaJK/en9mzfNhA2691u1d6jGq5Vg= 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 VI1PR04MB3198.eurprd04.prod.outlook.com (2603:10a6:802:9::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.14; Mon, 20 Sep 2021 21:42:42 +0000 Received: from VI1PR04MB5136.eurprd04.prod.outlook.com ([fe80::e157:3280:7bc3:18c4]) by VI1PR04MB5136.eurprd04.prod.outlook.com ([fe80::e157:3280:7bc3:18c4%5]) with mapi id 15.20.4523.018; Mon, 20 Sep 2021 21:42:42 +0000 From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Linus Walleij , Andrew Lunn , Vivien Didelot , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Jakub Kicinski , Bartosz Golaszewski , Wolfram Sang , linux-i2c@vger.kernel.org, Mark Brown , linux-spi@vger.kernel.org, =?utf-8?q?Alvin?= =?utf-8?q?_=C5=A0ipraga?= , Lino Sanfilippo Subject: [PATCH net 2/2] net: dsa: realtek: register the MDIO bus under devres Date: Tue, 21 Sep 2021 00:42:09 +0300 Message-Id: <20210920214209.1733768-3-vladimir.oltean@nxp.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210920214209.1733768-1-vladimir.oltean@nxp.com> References: <20210920214209.1733768-1-vladimir.oltean@nxp.com> X-ClientProxiedBy: AM0PR04CA0092.eurprd04.prod.outlook.com (2603:10a6:208:be::33) To VI1PR04MB5136.eurprd04.prod.outlook.com (2603:10a6:803:55::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost.localdomain (82.78.148.104) by AM0PR04CA0092.eurprd04.prod.outlook.com (2603:10a6:208:be::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.16 via Frontend Transport; Mon, 20 Sep 2021 21:42:41 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b4f46b65-c2ae-474e-c55f-08d97c7f9349 X-MS-TrafficTypeDiagnostic: VI1PR04MB3198: 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: 1/AjU+vOovXNXVOo7pdly+s/JMk2wJjwd+2myhwjUbmWElJkcQGxhrTO0PqRnKVkbGq0ezBmoYIZ8CPqjJkYd9gE5NXU16wAf9hl58J/XRUX+tmoglTfZJ4Sw5o2Ssr+IJslI18JlYwIgrj9bce1ha010moP8rE7X63pTCv1Ajkw0cO5ICyeZU2HMBWynRwo1IuBvBQ9Z5FQFBC258sHRaGxExVgm9RN35zfhgHiEv3Fyb6edsV/5EGcWl33ugsexzAtV0K4sid8HjBut8HVPRuQSRE5MljXnzY7nF5RrwqvKx5OLS2mCBexSYA+qsYzak9IwYujd0q+hwglI8NHQezlkMBK57UP6QC/Celj7+PS82Ue9nhhS0GF2xEnnZ3TNQFBUgk5zkQ+VFKLZ6DRdvPa5gLoJjK8TIVkNf5mIfZ6Uy++yDnr0PhkSY+d/LN/DhhBLxRoQKBNErFmmsMkOMJN7WcIvxhHgwneQZ/svlvR+XG6lVjYJqg43l4SP4g2tO1Hy9iJu1Z2qNKFxWRvoAIEcrTWGmum+0Y1aqzC+H4ffAzKa2P+slhpc4jDIWl/bjVeAREpgvwgf8pGxsLwkjYG5PB+aFpaUsF3gAsg3748YXEpKaIt7g1BtsQcT2WqhR3w87BwB7wh8D8AjJmnXi6T6tu2xBBRcq+IYOurYjA90loKvOwDkvQvMg8QJIxZ1RpnckrpeUQayvmsjmV/TQ== 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)(366004)(396003)(376002)(39860400002)(136003)(52116002)(38100700002)(38350700002)(4326008)(1076003)(44832011)(7416002)(83380400001)(66946007)(26005)(6486002)(8936002)(2616005)(8676002)(6512007)(6916009)(956004)(2906002)(66574015)(478600001)(66476007)(66556008)(316002)(54906003)(36756003)(186003)(86362001)(6506007)(5660300002)(6666004);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?q?TEnf52VHbI5HSjpmgLGuM/p+vU3g?= =?utf-8?q?yk2JDpnA8gb4Xea5L9GSizkwxtMAP+dspC+EDYSoS1a/4r9RwHpsF6CIFqtuEWBKF?= =?utf-8?q?WsPLqxFDIS7JTwozfS6335tB3792OAL9wlx54+qS844gGia0W1BApHTKJTenn+gDH?= =?utf-8?q?AW4bw5wAWQpc+Acz6dMydZRVebI7TO9d/ScjNxSriLKkiMD9Q6VK9n0KBfyFoW8th?= =?utf-8?q?R12kNW2iZT9zCkzXqDI1SVOIEEi/WfCpRu3Xi4prFY1gIFrnG7cPlMh2BJA4VSuPO?= =?utf-8?q?+DUDSy29iEUonhbpXDAIubbIYK2lOpZ0YzDbJHPfFlbvsefHJoVYk2190DCtrq0W4?= =?utf-8?q?/iai4LqudCMzP4nQUhacPsxth9q8beqj32OECxvGj/0vBiPH6CQl7bCtVCKME0vb8?= =?utf-8?q?SV/lHJQ+M0QFtavJx0XiyeGPyWCODTl/XFmGYBje5HufSc9+IInZkjohUxfRB4wWl?= =?utf-8?q?7BbFkLiUMqmR1kUiweQoRHmi6nCF+1pKo3lVZKOBPGZ1GhRvikMtgs1TZwSoKV0et?= =?utf-8?q?2yJNyzoSS4kZihEnECfYviaiyD3AM/hcj5jBBM1mvtCbYhe22nzh6tTEuiigRDKal?= =?utf-8?q?WtJuc02+EAGMy2m1lPg6VfGvLE9m/BBoXdE0ElujppvzON3Adaj0ObFqr4MZt4qfY?= =?utf-8?q?q0/8vnLUNrJ6y1ABvIf3zusWT++JidajY2AL8abjo812BGW1zmLsJQbSKqNjvoMpM?= =?utf-8?q?4lHTKN3m7VT4B1b9wVeSuy6qnARfF1c/EDdmn32XjafM3zznPjGVykNlqgpsBnS8u?= =?utf-8?q?GMVvDecCmpdE2l8EJAJsxrUuOvt2rAMp0y8M1S6QgI+EOsv+H4f3s0GFXTXLvvERR?= =?utf-8?q?FURXd0OTk5jXtzsW47Vx5Cqex6eqfpOH15pPTJuwhG96kOzXutOXZNCPOURONKI3V?= =?utf-8?q?KH/adtTEnpKkGOCgsJRqUUa1y0GjVl0Om0tEpZg5GxltcYNEY/nrxY5ZSW8xnmPwH?= =?utf-8?q?SwV3CApFuLBRWNtn4+6Bac++b5JjtrlCvv5oBu1bEm0glrKqFJaF75Uz2xyWNbF1S?= =?utf-8?q?v8rNp0yxlBNrey8j/nYCDAZmz6SqNtIDz0WfdC5Rq1QSjT5lxMTUOPWaucGglUO+4?= =?utf-8?q?q9d0FHruOcfmF4mXa/ZxUVyROI0NS7yIi0Xu7j4REsidVX46QHZOffH6iiTMEEz9x?= =?utf-8?q?M6uS5fTeuKjRYMeEErrCeg9wtYDzCEIWk7wgBo/+nXHzxqepV8++DoDK4UJkOLgRQ?= =?utf-8?q?Oa/S0DnP7WrknW4hzAv5SLhPUOfpGmlStjv2sOhRw24a+YL6LoWGem9z5FBRkD2Cf?= =?utf-8?q?xNPyZN456kE0Dcoe?= X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: b4f46b65-c2ae-474e-c55f-08d97c7f9349 X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2021 21:42:42.5021 (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: 06wUz0y9XOPTAZc3wisqQ1mawgRvXIN+j/DvcmEcycpq0ahR4lPXqkwnOQ6o4MYMXOxBuM7LGYAMYgTn/Yz1nA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB3198 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org The Linux device model permits both the ->shutdown and ->remove driver methods to get called during a shutdown procedure. Example: a DSA switch which sits on an SPI bus, and the SPI bus driver calls this on its ->shutdown method: spi_unregister_controller -> device_for_each_child(&ctlr->dev, NULL, __unregister); -> spi_unregister_device(to_spi_device(dev)); -> device_del(&spi->dev); So this is a simple pattern which can theoretically appear on any bus, although the only other buses on which I've been able to find it are I2C: i2c_del_adapter -> device_for_each_child(&adap->dev, NULL, __unregister_client); -> i2c_unregister_device(client); -> device_unregister(&client->dev); The implication of this pattern is that devices on these buses can be unregistered after having been shut down. The drivers for these devices might choose to return early either from ->remove or ->shutdown if the other callback has already run once, and they might choose that the ->shutdown method should only perform a subset of the teardown done by ->remove (to avoid unnecessary delays when rebooting). So in other words, the device driver may choose on ->remove to not do anything (therefore to not unregister an MDIO bus it has registered on ->probe), because this ->remove is actually triggered by the device_shutdown path, and its ->shutdown method has already run and done the minimally required cleanup. This used to be fine until the blamed commit, but now, the following BUG_ON triggers: void mdiobus_free(struct mii_bus *bus) { /* For compatibility with error handling in drivers. */ if (bus->state == MDIOBUS_ALLOCATED) { kfree(bus); return; } BUG_ON(bus->state != MDIOBUS_UNREGISTERED); bus->state = MDIOBUS_RELEASED; put_device(&bus->dev); } In other words, there is an attempt to free an MDIO bus which was not unregistered. The attempt to free it comes from the devres release callbacks of the SPI device, which are executed after the device is unregistered. I'm not saying that the fact that MDIO buses allocated using devres would automatically get unregistered wasn't strange. I'm just saying that the commit didn't care about auditing existing call paths in the kernel, and now, the following code sequences are potentially buggy: (a) devm_mdiobus_alloc followed by plain mdiobus_register, for a device located on a bus that unregisters its children on shutdown. After the blamed patch, either both the alloc and the register should use devres, or none should. (b) devm_mdiobus_alloc followed by plain mdiobus_register, and then no mdiobus_unregister at all in the remove path. After the blamed patch, nobody unregisters the MDIO bus anymore, so this is even more buggy than the previous case which needs a specific bus configuration to be seen, this one is an unconditional bug. In this case, the Realtek drivers fall under category (b). To solve it, we can register the MDIO bus under devres too, which restores the previous behavior. Fixes: ac3a68d56651 ("net: phy: don't abuse devres in devm_mdiobus_register()") Reported-by: Lino Sanfilippo Reported-by: Alvin Šipraga Signed-off-by: Vladimir Oltean Reviewed-by: Andrew Lunn Acked-by: Linus Walleij --- drivers/net/dsa/realtek-smi-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/dsa/realtek-smi-core.c b/drivers/net/dsa/realtek-smi-core.c index dd2f0d6208b3..2fcfd917b876 100644 --- a/drivers/net/dsa/realtek-smi-core.c +++ b/drivers/net/dsa/realtek-smi-core.c @@ -368,7 +368,7 @@ int realtek_smi_setup_mdio(struct realtek_smi *smi) smi->slave_mii_bus->parent = smi->dev; smi->ds->slave_mii_bus = smi->slave_mii_bus; - ret = of_mdiobus_register(smi->slave_mii_bus, mdio_np); + ret = devm_of_mdiobus_register(smi->dev, smi->slave_mii_bus, mdio_np); if (ret) { dev_err(smi->dev, "unable to register MDIO bus %s\n", smi->slave_mii_bus->id);