From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 26248C352A4 for ; Mon, 10 Feb 2020 12:45:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E99E42051A for ; Mon, 10 Feb 2020 12:45:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581338710; bh=Z1y4n+3wknrIgxXE+LAJc0Sz2YlFYPXTSwCitbBiRVY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=Vz/ZLJiUGjJGFHEzix0VwNSp5AdU7ED5iK6SHyDzf1ekghMP7XrtCQhcJOiMmfXCL E/1/qTu6WZhK72sU4ror42NtzguDS6PQ2PBBS+rTjiNDqBF4Itjgg99m1PjnZuKlt3 7T04GZ/g8Qth04rXFXEo1nm1pUPuNUSRUpupX6qo= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730775AbgBJMpJ (ORCPT ); Mon, 10 Feb 2020 07:45:09 -0500 Received: from mail.kernel.org ([198.145.29.99]:41670 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729830AbgBJMky (ORCPT ); Mon, 10 Feb 2020 07:40:54 -0500 Received: from localhost (unknown [209.37.97.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4D161208C3; Mon, 10 Feb 2020 12:40:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581338453; bh=Z1y4n+3wknrIgxXE+LAJc0Sz2YlFYPXTSwCitbBiRVY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=C4T4MQ+0M7PiJOuzCExP/tsCdapQJA4CUZKKo/MrzcbfLR3v0g2p0sdEUwMyuQgRn ya8Cj4oN1SAO8OALSQ2upge2FRMebZ+Jh3cVUFWfCTtWyFLgDi39NOM+bATONz0yrj La7BWzsYS4TN/dx2b6gKEReu95zFFKOM0Gur8Bwc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josef Bacik , David Sterba Subject: [PATCH 5.5 200/367] btrfs: free block groups after freeing fs trees Date: Mon, 10 Feb 2020 04:31:53 -0800 Message-Id: <20200210122443.012853267@linuxfoundation.org> X-Mailer: git-send-email 2.25.0 In-Reply-To: <20200210122423.695146547@linuxfoundation.org> References: <20200210122423.695146547@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Josef Bacik commit 4e19443da1941050b346f8fc4c368aa68413bc88 upstream. Sometimes when running generic/475 we would trip the WARN_ON(cache->reserved) check when free'ing the block groups on umount. This is because sometimes we don't commit the transaction because of IO errors and thus do not cleanup the tree logs until at umount time. These blocks are still reserved until they are cleaned up, but they aren't cleaned up until _after_ we do the free block groups work. Fix this by moving the free after free'ing the fs roots, that way all of the tree logs are cleaned up and we have a properly cleaned fs. A bunch of loops of generic/475 confirmed this fixes the problem. CC: stable@vger.kernel.org # 4.9+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/disk-io.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -4026,11 +4026,18 @@ void __cold close_ctree(struct btrfs_fs_ invalidate_inode_pages2(fs_info->btree_inode->i_mapping); btrfs_stop_all_workers(fs_info); - btrfs_free_block_groups(fs_info); - clear_bit(BTRFS_FS_OPEN, &fs_info->flags); free_root_pointers(fs_info, true); + /* + * We must free the block groups after dropping the fs_roots as we could + * have had an IO error and have left over tree log blocks that aren't + * cleaned up until the fs roots are freed. This makes the block group + * accounting appear to be wrong because there's pending reserved bytes, + * so make sure we do the block group cleanup afterwards. + */ + btrfs_free_block_groups(fs_info); + iput(fs_info->btree_inode); #ifdef CONFIG_BTRFS_FS_CHECK_INTEGRITY