From patchwork Mon May 13 03:39:10 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Tobin C. Harding" X-Patchwork-Id: 10940207 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 6F5F076 for ; Mon, 13 May 2019 03:40:36 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 61EA020502 for ; Mon, 13 May 2019 03:40:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 557FD26E38; Mon, 13 May 2019 03:40:36 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 05FB820502 for ; Mon, 13 May 2019 03:40:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727515AbfEMDkU (ORCPT ); Sun, 12 May 2019 23:40:20 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:51421 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727202AbfEMDkU (ORCPT ); Sun, 12 May 2019 23:40:20 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 072F7221AD; Sun, 12 May 2019 23:40:19 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 12 May 2019 23:40:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:date:from :message-id:mime-version:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=2FlEJdf2fi3fJ5B4N RVr7xTzZV11Nurruym7Rqoj6sE=; b=EQlQ7R49I/nSEGF9TKzS4iTWhGsFwsJN8 oNkPN7E7hed7HHnSRABYN17LKtv9T1oEFNtTJUJyovG8BaslPSK8Hsk/2KaYGwdE vORNsRanDIEU3+5LMR1vpGl10hkFJZPkRTqZAqnkBuwet2G14PTQqLm6KYUMfzJq xJj5XVqkSi3htu4E7B8CkvGO60GGId9VGMrt3cgy4rYmpSzLgmt9INvvQdNXSJA2 rZljskz4V+7JRCazGKGd+WkpVnB50iSyeKqZomDsSpl07xzQKaYZjgLjbCA+/9wd jKfkLJj61/G4SN9rEh+HQHFGXx30zIIRCP94M6TZHc50pUXLpY36w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrleefgdejudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkofgggfestdekredtredttdenucfhrhhomhepfdfvohgsihhnucev rdcujfgrrhguihhnghdfuceothhosghinheskhgvrhhnvghlrdhorhhgqeenucfkphepud dvgedrudeiledrudeirddukeehnecurfgrrhgrmhepmhgrihhlfhhrohhmpehtohgsihhn sehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from eros.localdomain (124-169-16-185.dyn.iinet.net.au [124.169.16.185]) by mail.messagingengine.com (Postfix) with ESMTPA id 285B08005C; Sun, 12 May 2019 23:40:14 -0400 (EDT) From: "Tobin C. Harding" To: Chris Mason , Josef Bacik , David Sterba Cc: "Tobin C. Harding" , Greg Kroah-Hartman , "Rafael J. Wysocki" , linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/2] Fix kobject error path memleaks Date: Mon, 13 May 2019 13:39:10 +1000 Message-Id: <20190513033912.3436-1-tobin@kernel.org> X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, Is it ok to send patches during the merge window? Applies on top of Linus' mainline tag: v5.1, happy to rebase if there are conflicts. While auditing kobject_init_and_add() calls throughout the kernel it was found that btrfs potentially has a couple of memleaks in the error path code for kobject_init_and_add(). Failing calls to kobject_init_and_add() should be followed by a call to kobject_put() since kobject_init_and_add() always calls kobject_init(). Of note, adding kobject_put() causes the release method to be called if kobject_init_and_add() fails. For patch #1 this means we don't have to manually free the space_info or call percpu_counter_destroy() since these are both done by the release method. In the second patch, I believe the added call to kobject_put() fits in with the fs_devices lifecycle assumptions of open_ctree() but please could you review since I am new to this code. CC'ing the kobject maintainers/reviewers also. Thanks, Tobin. Tobin C. Harding (2): fs: btrfs: Fix error path kobject memory leak fs: btrfs: Don't leak memory when failing add fsid fs/btrfs/extent-tree.c | 3 +-- fs/btrfs/sysfs.c | 7 ++++++- 2 files changed, 7 insertions(+), 3 deletions(-)