From patchwork Tue Apr 25 08:01:17 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Qu Wenruo X-Patchwork-Id: 9697681 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6DAEA601D3 for ; Tue, 25 Apr 2017 08:01:36 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7C20827D4A for ; Tue, 25 Apr 2017 08:01:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 70AC6285E2; Tue, 25 Apr 2017 08:01: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=-6.9 required=2.0 tests=BAYES_00,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 F03C32845E for ; Tue, 25 Apr 2017 08:01:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1176329AbdDYIBe (ORCPT ); Tue, 25 Apr 2017 04:01:34 -0400 Received: from cn.fujitsu.com ([59.151.112.132]:8789 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1167147AbdDYIBc (ORCPT ); Tue, 25 Apr 2017 04:01:32 -0400 X-IronPort-AV: E=Sophos;i="5.22,518,1449504000"; d="scan'208";a="18127682" Received: from unknown (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 25 Apr 2017 16:01:30 +0800 Received: from G08CNEXCHPEKD01.g08.fujitsu.local (unknown [10.167.33.80]) by cn.fujitsu.com (Postfix) with ESMTP id 35CD547E6344; Tue, 25 Apr 2017 16:01:26 +0800 (CST) Received: from localhost.localdomain (10.167.226.34) by G08CNEXCHPEKD01.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 25 Apr 2017 16:01:25 +0800 From: Qu Wenruo To: , Subject: [PATCH] btrfs-progs: Fix memory leak when 0 sized block group item is found Date: Tue, 25 Apr 2017 16:01:17 +0800 Message-ID: <20170425080117.18694-1-quwenruo@cn.fujitsu.com> X-Mailer: git-send-email 2.12.2 MIME-Version: 1.0 X-Originating-IP: [10.167.226.34] X-yoursite-MailScanner-ID: 35CD547E6344.ACD2A X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: quwenruo@cn.fujitsu.com 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 When a 0 sized block group item is found, set_extent_bits() will not really set any bits. While set_state_private() still inserts allocated block group cache into block group extent_io_tree. So at close_ctree() time, we won't free the private block group cache stored since we can't find any bit set for the 0 sized block group. To fix it, at btrfs_read_block_groups() we skip any 0 sized block group, so such leak won't happen. Signed-off-by: Qu Wenruo --- extent-tree.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/extent-tree.c b/extent-tree.c index 3e32e43b..b12ee290 100644 --- a/extent-tree.c +++ b/extent-tree.c @@ -3250,6 +3250,7 @@ int btrfs_read_block_groups(struct btrfs_root *root) } leaf = path->nodes[0]; btrfs_item_key_to_cpu(leaf, &found_key, path->slots[0]); + cache = kzalloc(sizeof(*cache), GFP_NOFS); if (!cache) { ret = -ENOMEM; @@ -3266,6 +3267,17 @@ int btrfs_read_block_groups(struct btrfs_root *root) if (found_key.offset == 0) key.objectid++; btrfs_release_path(path); + + /* + * Skip 0 sized block group, don't insert them into block + * group cache tree, as its length is 0, it won't get + * freed at close_ctree() time. + */ + if (found_key.offset == 0) { + free(cache); + continue; + } + cache->flags = btrfs_block_group_flags(&cache->item); bit = 0; if (cache->flags & BTRFS_BLOCK_GROUP_DATA) {