Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp1906181rwi; Thu, 20 Oct 2022 19:41:45 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7997C1pkawgd3QI2V6zCkEL9Uzhoq0SXjyqH8Y77nWNUkRtJdmWAvBLmxWV7gWrCEasoj+ X-Received: by 2002:a17:90b:3505:b0:20d:2c35:9834 with SMTP id ls5-20020a17090b350500b0020d2c359834mr19331384pjb.122.1666320094460; Thu, 20 Oct 2022 19:41:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666320094; cv=none; d=google.com; s=arc-20160816; b=pJxCwlRzaI+Aexu1ERu/vlJMzPGufuZSiU9WSRcCQwe8UyQbivyH7tWBZ6rjCbBKhr rdjjrxUImbmmQXjGzLcdmqEvCKchtFeiJhYbWx2U+ogedF1m85S2xk2V7905dIti/5tr MaM13U/NYqYEcv4TQWG4ixdHEsXXMHScUC1h1R2lvBgmIJKLlYdNDAFDXiv5B1R2B5nI p0V6YNxEG7nIGDCmJaqZZundXeCwqyMG3j8ImnJPvcG6p8JWGRvw/zFgjq0yyIInTN2D qqDBaYP3le833iddxs8xFeTm5G3D7zlD8JCRyc/GZ8rtF480RjInhumWYbjOKrUlxwnS WvJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=dyGVpi/cxfdKsPC0auDFM0qgMAIU47NidVfdyPK5ykE=; b=IM/aZ5Czw/QvfoM/Z6k73kWhW0Wec1XojDbp/FQ6nzqVS4u6Z7bBS+CG7kpa57k6Qi 1ulb3Dcg5e6S39DkRgre+b+R91GqLjDtXFvq7V1O73TaGT7gtD0PDM2IVe9UVRdaF8N6 6EFgUdxmHBg24EAV+6Ul2I3sv4Bp5t5d2fa9bMSICMyfsEViqAUxHBr4TPeD6UnID+uX wGQrISiledlEUPn8jAm68Si7VUCoYES3XX+taFNOwso4BNDQsaz+1HakSGcOd3+1wgU6 A/7TlcTMXxDf7rxQSo3cqx6825pTOY5V62GDqB64WvjLjnPZDZUyEzyDWHR58qIPJG+d jBHA== ARC-Authentication-Results: i=1; mx.google.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=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x7-20020a628607000000b0052dccbf4079si21403175pfd.220.2022.10.20.19.41.17; Thu, 20 Oct 2022 19:41:34 -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; 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=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230018AbiJUCXJ (ORCPT + 99 others); Thu, 20 Oct 2022 22:23:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37596 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229980AbiJUCWz (ORCPT ); Thu, 20 Oct 2022 22:22:55 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A72A232E54 for ; Thu, 20 Oct 2022 19:22:51 -0700 (PDT) Received: from dggpemm500022.china.huawei.com (unknown [172.30.72.57]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4MtpCN0WmtzHvCB; Fri, 21 Oct 2022 10:22:40 +0800 (CST) Received: from dggpemm500007.china.huawei.com (7.185.36.183) by dggpemm500022.china.huawei.com (7.185.36.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 21 Oct 2022 10:22:40 +0800 Received: from huawei.com (10.175.103.91) by dggpemm500007.china.huawei.com (7.185.36.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 21 Oct 2022 10:22:36 +0800 From: Yang Yingliang To: , , , , , , CC: , , , , , , , , , , , , , , , Subject: [PATCH 01/11] kset: fix documentation for kset_register() Date: Fri, 21 Oct 2022 10:20:52 +0800 Message-ID: <20221021022102.2231464-2-yangyingliang@huawei.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20221021022102.2231464-1-yangyingliang@huawei.com> References: <20221021022102.2231464-1-yangyingliang@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.103.91] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemm500007.china.huawei.com (7.185.36.183) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org kset_register() is currently used in some places without calling kset_put() in error path, because the callers think it should be kset internal thing to do, but the driver core can not know what caller doing with that memory at times. The memory could be freed both in kset_put() and error path of caller, if it is called in kset_register(). So make the function documentation more explicit about calling kset_put() in the error path of caller. Signed-off-by: Yang Yingliang --- lib/kobject.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/kobject.c b/lib/kobject.c index a0b2dbfcfa23..6da04353d974 100644 --- a/lib/kobject.c +++ b/lib/kobject.c @@ -834,6 +834,9 @@ EXPORT_SYMBOL_GPL(kobj_sysfs_ops); /** * kset_register() - Initialize and add a kset. * @k: kset. + * + * If this function returns an error, kset_put() must be called to + * properly clean up the memory associated with the object. */ int kset_register(struct kset *k) { -- 2.25.1