Message ID | 20230406093056.33916-3-frank.li@vivo.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp894736vqo; Thu, 6 Apr 2023 02:45:22 -0700 (PDT) X-Google-Smtp-Source: AKy350ZhdyrYlTnJMY3Z5kxLZelaX5DkEXD6jqMs2ABX3AMruUTq5uumgJSSZ2PZvg+iNxsd7LDz X-Received: by 2002:a17:903:22cd:b0:1a2:8924:224d with SMTP id y13-20020a17090322cd00b001a28924224dmr11322404plg.59.1680774322065; Thu, 06 Apr 2023 02:45:22 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1680774322; cv=pass; d=google.com; s=arc-20160816; b=LKVVRcoSFE36lswRXdZ58E5Obg7gw/LIMIZQy3n+ijFIZK1Ckcy4GZElexeByT/h1Y qYEY8BAWMUy4cXnylhg1ZiIlX9fjvW8ukrno7/RXzCEvWAoPyG1jbT4WjVe2CJInUk8O e9PwZ/HloQDtl4jmv2vTIsz/ppNvMvsK9ccuZOvF6KWM5Zu2swMlGSRiMdeOvbf4M/DE 04FufgfXD3zcvbVMKIek+EsVhHfP/My/2IqSZDTMIr5dcWUXIj003tnWKXdIN385KEnv 4CkZt1twgriZhzxAUs1YrVzA1lHCYysqG0Ubl16RmNG30YkYWThlc/Pyh2d4jt/QJt+a XyKw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=hxFWt74cFA6U7xiEQPD3j3AhIO/HZzzekr8xd1KIoPM=; b=T2fb66D9AI3Eekzw/bcFIpghy4Sr/3eJwhQCZcYiCIiUqlMGLtEwRBGVYbC+45/HVC RyHUgmnPSY1bCLMICPElVD5JC0g5B760kDqStLUR1MufWm+DE9XgbQ5pZGoFOvETxKI2 M42NUl8IA09S2G6pWo1ocLz78+Xpb8Zy3E3LYKX3pDHTO3xQo/IyCK50b1B+AcUEieb3 FTa5plb6DN+6vRk4s/e0/1OeG0Csh0c6yzTN4Uv6fyG2sl/ga6xbu6tJY9toZLUHKmQq 4ZNDiWTrXbFNizOoT908sfYTPcdPmiwmpfirCSx8dirvp3VamoZlA/v05r5VPs90dYph GxyQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@vivo.com header.s=selector2 header.b=cDv1Gdbh; arc=pass (i=1 spf=pass spfdomain=vivo.com dkim=pass dkdomain=vivo.com dmarc=pass fromdomain=vivo.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=vivo.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x28-20020a634a1c000000b0050f66d4e070si886999pga.417.2023.04.06.02.45.09; Thu, 06 Apr 2023 02:45:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@vivo.com header.s=selector2 header.b=cDv1Gdbh; arc=pass (i=1 spf=pass spfdomain=vivo.com dkim=pass dkdomain=vivo.com dmarc=pass fromdomain=vivo.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=vivo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236464AbjDFJb3 (ORCPT <rfc822;lkml4gm@gmail.com> + 99 others); Thu, 6 Apr 2023 05:31:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41586 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236438AbjDFJbZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 6 Apr 2023 05:31:25 -0400 Received: from APC01-TYZ-obe.outbound.protection.outlook.com (mail-tyzapc01on2118.outbound.protection.outlook.com [40.107.117.118]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F3CE476A8; Thu, 6 Apr 2023 02:31:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QQKq+Mx6Sut3+d3f9C3nCm82dNBsnY3dgo411jPS9hY/SihNY386LWQ99oFudKjmP6njdERzuiPdteSQuUGAarkw6+baUyx/YcgQNGTjLEWTmDZsEQzn402Gy8UhTA3uQiJl8ToAXLcBRCVxbxx84V97+3Y+7hElqJqlwuiwYj/p2u6MecX6PrbKc2mqrET5x2rkcCC40YzMcntjpukkUxEnsIaqfJHvL5pgaZkqVeX8xoY06IGZNM6MHmoqBHsu/d5auNASI+bXZfn689T0gK8qSXjQ7sMqMh2bnbNstSqXXRGyzzlpKb6ydt7Cnetg+gYcZ9hd70aeCDsufMgM/Q== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hxFWt74cFA6U7xiEQPD3j3AhIO/HZzzekr8xd1KIoPM=; b=cUl0q6beqYnqamBXhT5H7mT/xZdKdgTQcbWXDxn2m5QCk4bzlaiILD2p82EJ01lIHi0D58CLJdALm4m8OgFKq1tafLbumK+kpxb95YfJnH8kRaIVac8NHDjZg4EFYycuTUWk0h/VgdwgWWXNYcel6mGzwG3AFAIyW6FTo/obGVHOIKHRPq0x+0ZZTgxmQ3fErdp2Sk+vq50vpVC6Zja+joV7/HnFP4DkgUOjeL30ycdfNTQtf00B/yU0gD2Q2loIe297VWDMp3zOQ1nrRT4VVjvD6Dgri3BY2v/ccmEJnjRek0Pu8RzFUTOOO0s6vhXFMbhUdVhmC4cXaubqiEXMFw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vivo.com; dmarc=pass action=none header.from=vivo.com; dkim=pass header.d=vivo.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vivo.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hxFWt74cFA6U7xiEQPD3j3AhIO/HZzzekr8xd1KIoPM=; b=cDv1Gdbh2s3AOWCOyBdL96C1SpAhDfABo1IWK3qbMBJskfdPOggh3DmXLYzgTPFDXo0tlPHLSHwoOVLllfqMtKCJcYkKTOAhjE8r2Id1PZJptK+3am4o1aPSNs0X0261cRxg4FdN44WxAnuoajjYOjEhB60Wpqa0UEtQaZc4tiChd0e3PZJZjIHNmemB9Mrkco5g8mkJp7S9yCl+1yFNwb02VGZ75toxFS0ODun61+O2sEBs3R7fIf0Vl9ZVF5x3RRcI14tPV6uYZCIV7DFPFPHAiocypvxknhFZMmGIzpxOaVQenYZKoSZ1geI7Uh1/emSNpIkLYz0Bll5W6i1rlA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=vivo.com; Received: from TYZPR06MB5275.apcprd06.prod.outlook.com (2603:1096:400:1f5::6) by PUZPR06MB5772.apcprd06.prod.outlook.com (2603:1096:301:f0::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6254.35; Thu, 6 Apr 2023 09:31:15 +0000 Received: from TYZPR06MB5275.apcprd06.prod.outlook.com ([fe80::16db:8a6e:6861:4bb]) by TYZPR06MB5275.apcprd06.prod.outlook.com ([fe80::16db:8a6e:6861:4bb%5]) with mapi id 15.20.6277.031; Thu, 6 Apr 2023 09:31:15 +0000 From: Yangtao Li <frank.li@vivo.com> To: xiang@kernel.org, chao@kernel.org, huyue2@coolpad.com, jefflexu@linux.alibaba.com, damien.lemoal@opensource.wdc.com, naohiro.aota@wdc.com, jth@kernel.org, gregkh@linuxfoundation.org, rafael@kernel.org Cc: linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Yangtao Li <frank.li@vivo.com> Subject: [PATCH 3/3] zonefs: convert to use kobject_is_added() Date: Thu, 6 Apr 2023 17:30:56 +0800 Message-Id: <20230406093056.33916-3-frank.li@vivo.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20230406093056.33916-1-frank.li@vivo.com> References: <20230406093056.33916-1-frank.li@vivo.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SG2P153CA0021.APCP153.PROD.OUTLOOK.COM (2603:1096:4:c7::8) To TYZPR06MB5275.apcprd06.prod.outlook.com (2603:1096:400:1f5::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TYZPR06MB5275:EE_|PUZPR06MB5772:EE_ X-MS-Office365-Filtering-Correlation-Id: 89492d96-0959-42d3-9c3d-08db3681aae8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +of1lPVNrqjBhtxdLYDRlXpSUQUexuwJo5zORGUqcoTOuD3RRZdxWbfpMHxHhFWRz1n9M4zx4I+m/I1TkTtVFWHfXzlkLGlNU6zfbhHPSYZA5gtvRPf//M3xifviCbPCGxW74znuViuKPxHfxNIN8udktO3hQFlg+HVmoSZl9rOmEKTkyRh0Pu1FKEG63GBs2yyZSlS6tU9Sn0reQFdapn4yfqtc19BSZt1aL8o8XrTKC4E0Q2dNYV6xvhaM9Dp8SO8p4VIreAu7R7do1i8iMW8UdjvgQEXsHWL18muZMUY5JI4t1P+V3EVh2i6X1v9IJx/ezcMtgnfRoPFLyOm6NoKBA1GG6FUdtX8TrREjUlb2mE63GZiefGnML3khk7CQLAU8detcltOwOazudfBLkn5kppqVdQzFDtNiKtMOG19pilpDG4Fc5WwV9c2vNpLE21h0lMrx+igdLmMV2/OFDIGOiV2er8D6lZ1khialTc56c0E5eKk3dGq3PfcmJL709K5QjvGTBqwvFkum+HdltBaVhdsc9PvZE7af+0j87gevtLXw3GgrjcoGFNm09nY6q4HFkQlIN3jvY4jhOzKuJ450UNLVmJkNHpwOe6/+j3rFH65eIbf5gJkYCqt6j/dx X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TYZPR06MB5275.apcprd06.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(4636009)(39860400002)(396003)(376002)(346002)(136003)(366004)(451199021)(86362001)(36756003)(2906002)(6666004)(2616005)(186003)(83380400001)(6486002)(6506007)(6512007)(107886003)(1076003)(26005)(8676002)(4326008)(66556008)(66946007)(66476007)(52116002)(316002)(5660300002)(38350700002)(38100700002)(41300700001)(478600001)(7416002)(8936002);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: lMO92vDo2PiinmK+5c8YUwipt+pEEdLz1T4Orjm6Cz1yFsMx+enxLGll44nNIU8s/e+eFk4tuM21297baNvI8UYNRy52wA0mzWYb6v7XkJDoJh6xXryuqx+3uRBceXvcLqLEbl8W+vtazYgMvAHfl2Jt154b8/qgzn1rVADUgRDDyHByNsjyBc3k3TY2tYN1yC492mpRRv7we+oK82g4U3mA5/gI5RCcXmfdQdQWvY4DtkB15W7wyH7G7jJNV+YC8b4SwenHNKnAJBtrn9mGzistOte4fzA9D0/ddW83UEcVm5xE9VDPErHuP2v5o6EzR+Oc/+ErKntEVUxq6MbB+98/zDpMUVk8jVqOXmXp7JripNCJ4CHHShoBFV6QVgqVPXinf0q1dUAcd96vZpJ5/y/fvea9IbbF+anewAnfIObca9NiWPnk/kKeQbYjovFb0q3eGJHw0QdrbHRlIwXdoYjO3VAFwE/PRUK8o2IR9ohEfpazqU1eswjry6C4T9T8Rh3ZpigOb+Z+wa+XC8PRoHkQ8Sc5HQZMXO+yBGuo/xvxoA6sML0ofkHCn3xWuG/SV8qTofYOBu/LSSlLWFV+uXGM3BmKnEjhk1Wjv7cyLMG5TUQPfuoUOYX5ncSZ8aq5/ouTybdHlg8ynCvWnY7FOLtsfpfhrJeWetvBZ6DOMPN5CzwezfanwcT5gn4ly4sHD5pCz2viIlR8NOR2sfkPPtUn+Jsie6AuFahjz3VqYhGzLOm1Uy53MPM6GekZ9O6enrnozCuuwEZM3mKpzg3LMuohljD1oRGght0/DjHF3jcINnfiTKPHwMTXs9bIF/Qzo41j8B6IpoWs9KUaN1Q3l7XqpnUVmDY1825gH872CoyXiSR0jG+/YdINIe9pnQ59SwItFY1eCiCG/3NfXi54ys6kYE4Ssf/0h6y9BV2j/ItlHsmvmiryixKB5YYITjxI9AO1XWJr4qYScyd8e3SQY4uPWK4tyxgss9hovQYiTHJQ2wn3N6tOfuGGc0fdt0MRWS0na9cIKEpxxzV5EsGOe6cLVf9PWjfXH6ueXafakabV8IT+wlSNFrJCvr3y/Dj1mYwNoIv24ierBN3Fl7V5ptR6JFNvAeTLxkE8SWgtUakNXRRzKb7jGYFnszINSuWjq/AxzhVRC4g2xSTPePj4mxJoDxTSQLnn/r2x+3nYjV4u9Sr9jfn07+O1hhnPQE2sWuklk7sA3qB/vCJFV905sHRsSX2uuc735FsNo70go4rfvQPWoIiB9Qir5Q9Fjje7Rb/ks992UtQI/PZuFOKdPVb0z9Nh+LZoqgkASWuU73gfco6esjuY+OlQS5+0qAcgc8giylsC0utynVBhEr/Y16g/Qu3AJc581m18UPFM+tbfvQsxGGXPj0ZhTLooiyJvjx6Q2MTEa5VEQRlSLL3BdbN1WlTG3Xu78Qhei9BasYCwM3DrCuxpxgsbPJevuSOvbWZ5TM/dYUyYFsjk2/gP7+B1v2XmW7FdVJ/DNOUu8UGjYV1T/oJwpMtS6i2wCK74FSwk8ygOA3xsJ/DuOULUrie8Vy0ZBm40z+tT80+AOK/U2tLygpqUSZv22WgzOMkW X-OriginatorOrg: vivo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 89492d96-0959-42d3-9c3d-08db3681aae8 X-MS-Exchange-CrossTenant-AuthSource: TYZPR06MB5275.apcprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2023 09:31:15.0418 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 923e42dc-48d5-4cbe-b582-1a797a6412ed X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: VLclSE4et47LFAX8qAr0rbSbYogvfxKwL0Kzh41GBFK4BqXHGeTMRW0RwsDFfxdOF5OwB6LAk274bGl10hORRA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PUZPR06MB5772 X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_PASS,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762419615117454297?= X-GMAIL-MSGID: =?utf-8?q?1762419615117454297?= |
Series |
[1/3] kobject: introduce kobject_is_added()
|
|
Commit Message
李扬韬
April 6, 2023, 9:30 a.m. UTC
Use kobject_is_added() instead of local `s_sysfs_registered` variables.
BTW kill kobject_del() directly, because kobject_put() actually covers
kobject removal automatically.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
---
fs/zonefs/sysfs.c | 11 +++++------
fs/zonefs/zonefs.h | 1 -
2 files changed, 5 insertions(+), 7 deletions(-)
Comments
On Thu, Apr 06, 2023 at 05:30:56PM +0800, Yangtao Li wrote: > Use kobject_is_added() instead of local `s_sysfs_registered` variables. > BTW kill kobject_del() directly, because kobject_put() actually covers > kobject removal automatically. > > Signed-off-by: Yangtao Li <frank.li@vivo.com> > --- > fs/zonefs/sysfs.c | 11 +++++------ > fs/zonefs/zonefs.h | 1 - > 2 files changed, 5 insertions(+), 7 deletions(-) > > diff --git a/fs/zonefs/sysfs.c b/fs/zonefs/sysfs.c > index 8ccb65c2b419..f0783bf7a25c 100644 > --- a/fs/zonefs/sysfs.c > +++ b/fs/zonefs/sysfs.c > @@ -101,8 +101,6 @@ int zonefs_sysfs_register(struct super_block *sb) > return ret; > } > > - sbi->s_sysfs_registered = true; You know this, why do you need to have a variable tell you this or not? > - > return 0; > } > > @@ -110,12 +108,13 @@ void zonefs_sysfs_unregister(struct super_block *sb) > { > struct zonefs_sb_info *sbi = ZONEFS_SB(sb); > > - if (!sbi || !sbi->s_sysfs_registered) How can either of these ever be true? Note, sbi should be passed here to this function, not the super block as that is now unregistered from the system. Looks like no one has really tested this codepath that much :( > + if (!sbi) > return; this can not ever be true, right? > > - kobject_del(&sbi->s_kobj); > - kobject_put(&sbi->s_kobj); > - wait_for_completion(&sbi->s_kobj_unregister); > + if (kobject_is_added(&sbi->s_kobj)) { Again, not needed. thanks, greg k-h
On 4/6/23 19:05, Greg KH wrote: > On Thu, Apr 06, 2023 at 05:30:56PM +0800, Yangtao Li wrote: >> Use kobject_is_added() instead of local `s_sysfs_registered` variables. >> BTW kill kobject_del() directly, because kobject_put() actually covers >> kobject removal automatically. >> >> Signed-off-by: Yangtao Li <frank.li@vivo.com> >> --- >> fs/zonefs/sysfs.c | 11 +++++------ >> fs/zonefs/zonefs.h | 1 - >> 2 files changed, 5 insertions(+), 7 deletions(-) >> >> diff --git a/fs/zonefs/sysfs.c b/fs/zonefs/sysfs.c >> index 8ccb65c2b419..f0783bf7a25c 100644 >> --- a/fs/zonefs/sysfs.c >> +++ b/fs/zonefs/sysfs.c >> @@ -101,8 +101,6 @@ int zonefs_sysfs_register(struct super_block *sb) >> return ret; >> } >> >> - sbi->s_sysfs_registered = true; > > You know this, why do you need to have a variable tell you this or not? If kobject_init_and_add() fails, zonefs_sysfs_register() returns an error and fill_super will also return that error. vfs will then call kill_super, which calls zonefs_sysfs_unregister(). For that case, we need to know that we actually added the kobj. > >> - >> return 0; >> } >> >> @@ -110,12 +108,13 @@ void zonefs_sysfs_unregister(struct super_block *sb) >> { >> struct zonefs_sb_info *sbi = ZONEFS_SB(sb); >> >> - if (!sbi || !sbi->s_sysfs_registered) > > How can either of these ever be true? Note, sbi should be passed here > to this function, not the super block as that is now unregistered from > the system. Looks like no one has really tested this codepath that much > :( > >> + if (!sbi) >> return; > > this can not ever be true, right? Yes it can, if someone attempt to mount a non zoned device. In that case, fill_super returns early without setting sb->s_fs_info but vfs still calls kill_super. > > >> >> - kobject_del(&sbi->s_kobj); >> - kobject_put(&sbi->s_kobj); >> - wait_for_completion(&sbi->s_kobj_unregister); >> + if (kobject_is_added(&sbi->s_kobj)) { > > Again, not needed. > > thanks, > > greg k-h
On Thu, Apr 06, 2023 at 07:13:38PM +0900, Damien Le Moal wrote: > On 4/6/23 19:05, Greg KH wrote: > > On Thu, Apr 06, 2023 at 05:30:56PM +0800, Yangtao Li wrote: > >> Use kobject_is_added() instead of local `s_sysfs_registered` variables. > >> BTW kill kobject_del() directly, because kobject_put() actually covers > >> kobject removal automatically. > >> > >> Signed-off-by: Yangtao Li <frank.li@vivo.com> > >> --- > >> fs/zonefs/sysfs.c | 11 +++++------ > >> fs/zonefs/zonefs.h | 1 - > >> 2 files changed, 5 insertions(+), 7 deletions(-) > >> > >> diff --git a/fs/zonefs/sysfs.c b/fs/zonefs/sysfs.c > >> index 8ccb65c2b419..f0783bf7a25c 100644 > >> --- a/fs/zonefs/sysfs.c > >> +++ b/fs/zonefs/sysfs.c > >> @@ -101,8 +101,6 @@ int zonefs_sysfs_register(struct super_block *sb) > >> return ret; > >> } > >> > >> - sbi->s_sysfs_registered = true; > > > > You know this, why do you need to have a variable tell you this or not? > > If kobject_init_and_add() fails, zonefs_sysfs_register() returns an error and > fill_super will also return that error. vfs will then call kill_super, which > calls zonefs_sysfs_unregister(). For that case, we need to know that we actually > added the kobj. Ok, but then why not just 0 out the kobject pointer here instead? That way you will always know if it's a valid pointer or not and you don't have to rely on some other variable? Use the one that you have already :) And you really don't even need to check anything, just pass in NULL to kobject_del() and friends, it should handle it. > >> - > >> return 0; > >> } > >> > >> @@ -110,12 +108,13 @@ void zonefs_sysfs_unregister(struct super_block *sb) > >> { > >> struct zonefs_sb_info *sbi = ZONEFS_SB(sb); > >> > >> - if (!sbi || !sbi->s_sysfs_registered) > > > > How can either of these ever be true? Note, sbi should be passed here > > to this function, not the super block as that is now unregistered from > > the system. Looks like no one has really tested this codepath that much > > :( > > > >> + if (!sbi) > >> return; > > > > this can not ever be true, right? > > Yes it can, if someone attempt to mount a non zoned device. In that case, > fill_super returns early without setting sb->s_fs_info but vfs still calls > kill_super. But you already had a sbi pointer in the place that this was called, so you "know" if you need to even call into here or not. You are having to look up the same pointer multiple times in this call chain, there's no need for that. thanks, greg k-h
On 4/6/23 19:26, Greg KH wrote: > On Thu, Apr 06, 2023 at 07:13:38PM +0900, Damien Le Moal wrote: >> On 4/6/23 19:05, Greg KH wrote: >>> On Thu, Apr 06, 2023 at 05:30:56PM +0800, Yangtao Li wrote: >>>> Use kobject_is_added() instead of local `s_sysfs_registered` variables. >>>> BTW kill kobject_del() directly, because kobject_put() actually covers >>>> kobject removal automatically. >>>> >>>> Signed-off-by: Yangtao Li <frank.li@vivo.com> >>>> --- >>>> fs/zonefs/sysfs.c | 11 +++++------ >>>> fs/zonefs/zonefs.h | 1 - >>>> 2 files changed, 5 insertions(+), 7 deletions(-) >>>> >>>> diff --git a/fs/zonefs/sysfs.c b/fs/zonefs/sysfs.c >>>> index 8ccb65c2b419..f0783bf7a25c 100644 >>>> --- a/fs/zonefs/sysfs.c >>>> +++ b/fs/zonefs/sysfs.c >>>> @@ -101,8 +101,6 @@ int zonefs_sysfs_register(struct super_block *sb) >>>> return ret; >>>> } >>>> >>>> - sbi->s_sysfs_registered = true; >>> >>> You know this, why do you need to have a variable tell you this or not? >> >> If kobject_init_and_add() fails, zonefs_sysfs_register() returns an error and >> fill_super will also return that error. vfs will then call kill_super, which >> calls zonefs_sysfs_unregister(). For that case, we need to know that we actually >> added the kobj. > > Ok, but then why not just 0 out the kobject pointer here instead? That > way you will always know if it's a valid pointer or not and you don't > have to rely on some other variable? Use the one that you have already :) but sbi->s_kobj is the kobject itself, not a pointer. I can still zero it out in case of error to avoid using the added s_sysfs_registered bool. I would need to check a field of s_kobj though, which is not super clean and makes the code dependent on kobject internals. Not super nice in my opinion, unless I am missing something. > And you really don't even need to check anything, just pass in NULL to > kobject_del() and friends, it should handle it.> >>>> - >>>> return 0; >>>> } >>>> >>>> @@ -110,12 +108,13 @@ void zonefs_sysfs_unregister(struct super_block *sb) >>>> { >>>> struct zonefs_sb_info *sbi = ZONEFS_SB(sb); >>>> >>>> - if (!sbi || !sbi->s_sysfs_registered) >>> >>> How can either of these ever be true? Note, sbi should be passed here >>> to this function, not the super block as that is now unregistered from >>> the system. Looks like no one has really tested this codepath that much >>> :( >>> >>>> + if (!sbi) >>>> return; >>> >>> this can not ever be true, right? >> >> Yes it can, if someone attempt to mount a non zoned device. In that case, >> fill_super returns early without setting sb->s_fs_info but vfs still calls >> kill_super. > > But you already had a sbi pointer in the place that this was called, so > you "know" if you need to even call into here or not. You are having to > look up the same pointer multiple times in this call chain, there's no > need for that. I am not following here. Either we check that we have sbi here in zonefs_sysfs_unregister(), or we conditionally call this function in zonefs_kill_super() with a "if (sbi)". Either way, we need to check since sbi can be NULL. > > thanks, > > greg k-h
On Thu, Apr 06, 2023 at 07:58:38PM +0900, Damien Le Moal wrote: > On 4/6/23 19:26, Greg KH wrote: > > On Thu, Apr 06, 2023 at 07:13:38PM +0900, Damien Le Moal wrote: > >> On 4/6/23 19:05, Greg KH wrote: > >>> On Thu, Apr 06, 2023 at 05:30:56PM +0800, Yangtao Li wrote: > >>>> Use kobject_is_added() instead of local `s_sysfs_registered` variables. > >>>> BTW kill kobject_del() directly, because kobject_put() actually covers > >>>> kobject removal automatically. > >>>> > >>>> Signed-off-by: Yangtao Li <frank.li@vivo.com> > >>>> --- > >>>> fs/zonefs/sysfs.c | 11 +++++------ > >>>> fs/zonefs/zonefs.h | 1 - > >>>> 2 files changed, 5 insertions(+), 7 deletions(-) > >>>> > >>>> diff --git a/fs/zonefs/sysfs.c b/fs/zonefs/sysfs.c > >>>> index 8ccb65c2b419..f0783bf7a25c 100644 > >>>> --- a/fs/zonefs/sysfs.c > >>>> +++ b/fs/zonefs/sysfs.c > >>>> @@ -101,8 +101,6 @@ int zonefs_sysfs_register(struct super_block *sb) > >>>> return ret; > >>>> } > >>>> > >>>> - sbi->s_sysfs_registered = true; > >>> > >>> You know this, why do you need to have a variable tell you this or not? > >> > >> If kobject_init_and_add() fails, zonefs_sysfs_register() returns an error and > >> fill_super will also return that error. vfs will then call kill_super, which > >> calls zonefs_sysfs_unregister(). For that case, we need to know that we actually > >> added the kobj. > > > > Ok, but then why not just 0 out the kobject pointer here instead? That > > way you will always know if it's a valid pointer or not and you don't > > have to rely on some other variable? Use the one that you have already :) > > but sbi->s_kobj is the kobject itself, not a pointer. Then it should not be there if the kobject is not valid as it should have been freed when the kobject_init_and_add() call failed, right? > I can still zero it out in > case of error to avoid using the added s_sysfs_registered bool. I would need to > check a field of s_kobj though, which is not super clean and makes the code > dependent on kobject internals. Not super nice in my opinion, unless I am > missing something. See above, if a kobject fails to be registered, just remove the whole object as it's obviously "dead" now and you can not trust it. > > And you really don't even need to check anything, just pass in NULL to > > kobject_del() and friends, it should handle it.> > >>>> - > >>>> return 0; > >>>> } > >>>> > >>>> @@ -110,12 +108,13 @@ void zonefs_sysfs_unregister(struct super_block *sb) > >>>> { > >>>> struct zonefs_sb_info *sbi = ZONEFS_SB(sb); > >>>> > >>>> - if (!sbi || !sbi->s_sysfs_registered) > >>> > >>> How can either of these ever be true? Note, sbi should be passed here > >>> to this function, not the super block as that is now unregistered from > >>> the system. Looks like no one has really tested this codepath that much > >>> :( > >>> > >>>> + if (!sbi) > >>>> return; > >>> > >>> this can not ever be true, right? > >> > >> Yes it can, if someone attempt to mount a non zoned device. In that case, > >> fill_super returns early without setting sb->s_fs_info but vfs still calls > >> kill_super. > > > > But you already had a sbi pointer in the place that this was called, so > > you "know" if you need to even call into here or not. You are having to > > look up the same pointer multiple times in this call chain, there's no > > need for that. > > I am not following here. Either we check that we have sbi here in > zonefs_sysfs_unregister(), or we conditionally call this function in > zonefs_kill_super() with a "if (sbi)". Either way, we need to check since sbi > can be NULL. In zonefs_kill_super() you have get the spi at the top of the function, so use that, don't make zonefs_sysfs_unregister() have to compute it again. But again, if the kobject fails to be registered, you have to treat the memory contained there as not valid and get rid of it as soon as possible. thanks, greg k-h
On 4/6/23 20:18, Greg KH wrote: > On Thu, Apr 06, 2023 at 07:58:38PM +0900, Damien Le Moal wrote: >> On 4/6/23 19:26, Greg KH wrote: >>> On Thu, Apr 06, 2023 at 07:13:38PM +0900, Damien Le Moal wrote: >>>> On 4/6/23 19:05, Greg KH wrote: >>>>> On Thu, Apr 06, 2023 at 05:30:56PM +0800, Yangtao Li wrote: >>>>>> Use kobject_is_added() instead of local `s_sysfs_registered` variables. >>>>>> BTW kill kobject_del() directly, because kobject_put() actually covers >>>>>> kobject removal automatically. >>>>>> >>>>>> Signed-off-by: Yangtao Li <frank.li@vivo.com> >>>>>> --- >>>>>> fs/zonefs/sysfs.c | 11 +++++------ >>>>>> fs/zonefs/zonefs.h | 1 - >>>>>> 2 files changed, 5 insertions(+), 7 deletions(-) >>>>>> >>>>>> diff --git a/fs/zonefs/sysfs.c b/fs/zonefs/sysfs.c >>>>>> index 8ccb65c2b419..f0783bf7a25c 100644 >>>>>> --- a/fs/zonefs/sysfs.c >>>>>> +++ b/fs/zonefs/sysfs.c >>>>>> @@ -101,8 +101,6 @@ int zonefs_sysfs_register(struct super_block *sb) >>>>>> return ret; >>>>>> } >>>>>> >>>>>> - sbi->s_sysfs_registered = true; >>>>> >>>>> You know this, why do you need to have a variable tell you this or not? >>>> >>>> If kobject_init_and_add() fails, zonefs_sysfs_register() returns an error and >>>> fill_super will also return that error. vfs will then call kill_super, which >>>> calls zonefs_sysfs_unregister(). For that case, we need to know that we actually >>>> added the kobj. >>> >>> Ok, but then why not just 0 out the kobject pointer here instead? That >>> way you will always know if it's a valid pointer or not and you don't >>> have to rely on some other variable? Use the one that you have already :) >> >> but sbi->s_kobj is the kobject itself, not a pointer. > > Then it should not be there if the kobject is not valid as it should > have been freed when the kobject_init_and_add() call failed, right? What do you mean freed ? the kboject itself is a field of zonefs sbi. So the kobject gets freed together with sbi. >> I can still zero it out in >> case of error to avoid using the added s_sysfs_registered bool. I would need to >> check a field of s_kobj though, which is not super clean and makes the code >> dependent on kobject internals. Not super nice in my opinion, unless I am >> missing something. > > See above, if a kobject fails to be registered, just remove the whole > object as it's obviously "dead" now and you can not trust it. Well yes, that is what s_sysfs_registered indicates, that the kobject is not valid. I do not understand what you mean with "just remove the whole object". >>> And you really don't even need to check anything, just pass in NULL to >>> kobject_del() and friends, it should handle it.> >>>>>> - >>>>>> return 0; >>>>>> } >>>>>> >>>>>> @@ -110,12 +108,13 @@ void zonefs_sysfs_unregister(struct super_block *sb) >>>>>> { >>>>>> struct zonefs_sb_info *sbi = ZONEFS_SB(sb); >>>>>> >>>>>> - if (!sbi || !sbi->s_sysfs_registered) >>>>> >>>>> How can either of these ever be true? Note, sbi should be passed here >>>>> to this function, not the super block as that is now unregistered from >>>>> the system. Looks like no one has really tested this codepath that much >>>>> :( >>>>> >>>>>> + if (!sbi) >>>>>> return; >>>>> >>>>> this can not ever be true, right? >>>> >>>> Yes it can, if someone attempt to mount a non zoned device. In that case, >>>> fill_super returns early without setting sb->s_fs_info but vfs still calls >>>> kill_super. >>> >>> But you already had a sbi pointer in the place that this was called, so >>> you "know" if you need to even call into here or not. You are having to >>> look up the same pointer multiple times in this call chain, there's no >>> need for that. >> >> I am not following here. Either we check that we have sbi here in >> zonefs_sysfs_unregister(), or we conditionally call this function in >> zonefs_kill_super() with a "if (sbi)". Either way, we need to check since sbi >> can be NULL. > > In zonefs_kill_super() you have get the spi at the top of the function, > so use that, don't make zonefs_sysfs_unregister() have to compute it > again. That I can do, yes. > > But again, if the kobject fails to be registered, you have to treat the > memory contained there as not valid and get rid of it as soon as > possible. If the kobject add failed, we never touch it thanks to s_sysfs_registered. I still do not see the issue here. > > thanks, > > greg k-h
diff --git a/fs/zonefs/sysfs.c b/fs/zonefs/sysfs.c index 8ccb65c2b419..f0783bf7a25c 100644 --- a/fs/zonefs/sysfs.c +++ b/fs/zonefs/sysfs.c @@ -101,8 +101,6 @@ int zonefs_sysfs_register(struct super_block *sb) return ret; } - sbi->s_sysfs_registered = true; - return 0; } @@ -110,12 +108,13 @@ void zonefs_sysfs_unregister(struct super_block *sb) { struct zonefs_sb_info *sbi = ZONEFS_SB(sb); - if (!sbi || !sbi->s_sysfs_registered) + if (!sbi) return; - kobject_del(&sbi->s_kobj); - kobject_put(&sbi->s_kobj); - wait_for_completion(&sbi->s_kobj_unregister); + if (kobject_is_added(&sbi->s_kobj)) { + kobject_put(&sbi->s_kobj); + wait_for_completion(&sbi->s_kobj_unregister); + } } int __init zonefs_sysfs_init(void) diff --git a/fs/zonefs/zonefs.h b/fs/zonefs/zonefs.h index 8175652241b5..4db0ea173220 100644 --- a/fs/zonefs/zonefs.h +++ b/fs/zonefs/zonefs.h @@ -238,7 +238,6 @@ struct zonefs_sb_info { unsigned int s_max_active_seq_files; atomic_t s_active_seq_files; - bool s_sysfs_registered; struct kobject s_kobj; struct completion s_kobj_unregister; };