Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1206434ybz; Wed, 22 Apr 2020 15:53:40 -0700 (PDT) X-Google-Smtp-Source: APiQypJF4nUlXNWFu//1bgK+zcXblhhO2NXlBTY1cfz+tYAWNlzl1xhINtWsDD5lxog3buwnBmLk X-Received: by 2002:a17:906:2410:: with SMTP id z16mr483344eja.1.1587596020715; Wed, 22 Apr 2020 15:53:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587596020; cv=none; d=google.com; s=arc-20160816; b=bN79z0O6JW+iIea8YbGoFuo5ABw8WH6/rLw+ZPmDr/QBzFZ7QcCusSvPJnj7DxCz0z idl99dvFakbJiIBZIGcRJCrynBdJvrbsYiBNKm9IEWNy5+x5D6NJbOsHkq7Magk6fQG3 bOzcFCxug8XQyirH/E2Ib0JaqfLd34sPJ6s88KY0MawTmDhLY71szJ6xPCgYUj9/YGd1 E1XWcG19hz30fxWWJOQOtdIVUlbxG/BwNAiBJdSVT9SIQrypL0uNP8Oi2GO19aODTk10 4G8TqQUQepPWc955juqqFEArfZlHo82u2c22NBcnC3EH/fXd/AQuKaMr7hXLy5ii75vE ceYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :reply-to:message-id:subject:cc:to:from:date; bh=/yPU1rVy2zfLPPFZwp889cWX9/WsgKhhap7NMWCwijE=; b=DB47jU76LKwodVaVXHueM1bie2wCas2/ysUTryIfhp9wR8o+ySaN6eCmqIrx2bKlKy ZOGQlhFBTaz8WPva0ORafzEsGnNDeDAMmFHHtqQbKy02lJcrjEW3vGz/I4J94TX3nxbQ OEZNEoxYKIjA6xrdljBbhZdIGSVQQfp882j0ExhlZCTEZrFMTLFkV1y+RIq7ntubmmnE 2MrBWJXxMf3UfcpqCcY2XgQYTCR/GeUTpdeFc/EJy2iDryyZwieG36+jtTeOROr9qyfA Lkr+shT0UUXX7BFai3UvzIAD1djQ7ZuacAekr+SHHNpXB5dcQBlmSHYK+kbnFUN238ou mbug== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x25si277435edi.76.2020.04.22.15.53.18; Wed, 22 Apr 2020 15:53:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726284AbgDVWvk (ORCPT + 99 others); Wed, 22 Apr 2020 18:51:40 -0400 Received: from mx2.suse.de ([195.135.220.15]:35348 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725839AbgDVWvj (ORCPT ); Wed, 22 Apr 2020 18:51:39 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 51A07ABC7; Wed, 22 Apr 2020 22:51:37 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 87993DA704; Thu, 23 Apr 2020 00:50:54 +0200 (CEST) Date: Thu, 23 Apr 2020 00:50:54 +0200 From: David Sterba To: Xiyu Yang Cc: Chris Mason , Josef Bacik , David Sterba , linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, yuanxzhang@fudan.edu.cn, kjlu@umn.edu, Xin Tan Subject: Re: [PATCH v2] btrfs: Fix block group leak when remove it fails Message-ID: <20200422225054.GU18421@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Xiyu Yang , Chris Mason , Josef Bacik , David Sterba , linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, yuanxzhang@fudan.edu.cn, kjlu@umn.edu, Xin Tan References: <1587437651-87784-1-git-send-email-xiyuyang19@fudan.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1587437651-87784-1-git-send-email-xiyuyang19@fudan.edu.cn> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 21, 2020 at 10:54:11AM +0800, Xiyu Yang wrote: > btrfs_remove_block_group() invokes btrfs_lookup_block_group(), which > returns a local reference of the blcok group that contains the given > bytenr to "block_group" with increased refcount. > > When btrfs_remove_block_group() returns, "block_group" becomes invalid, > so the refcount should be decreased to keep refcount balanced. > > The reference counting issue happens in several exception handling paths > of btrfs_remove_block_group(). When those error scenarios occur such as > btrfs_alloc_path() returns NULL, the function forgets to decrease its > refcnt increased by btrfs_lookup_block_group() and will cause a refcnt > leak. > > Fix this issue by jumping to "out_put_group" label and calling > btrfs_put_block_group() when those error scenarios occur. > > Signed-off-by: Xiyu Yang > Signed-off-by: Xin Tan Added to misc-next, thanks.