Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2307558imm; Mon, 28 May 2018 05:48:46 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpIFblJDxQhJi7W+4soHANoS5GfW5hmfAQH39vWnkhPTwkgDa/RF0HeXecXioVwcgullkiR X-Received: by 2002:a65:608c:: with SMTP id t12-v6mr10223290pgu.182.1527511726720; Mon, 28 May 2018 05:48:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527511726; cv=none; d=google.com; s=arc-20160816; b=djFAd3Q5iV0OjkWc5r7ivE9IC8PRIqQsxC6+GUOfunzg8E2UBjC4Lc4ezwzcGdu75W Yf2CKZwI72ocT1KMObuCl4R2DG1Wirrejsf3nlsuA1fYCxeVTnOlVYyguPuBQbyi82CF kREuNV6fQ4f5pRx0XXLnELjcuTZtbLqrI7ZuucT7gDCGZTIqwsbhK/nM1o+l+CN/o010 9A36fr9pG3c61UJKnpr0Hy4HiP9Gx6b6bQvuQVlR5jOTEaXeIpqwaFFMaft9FCcx5tpB a4EuoTn7rvE5oXzMNoPZtZmHG2CgX9Nt5in9Cx98mIc6kmU4geTQigu3TaVxxyhuRvGY 0u9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=evQyL8UuO/9j1d2yGPcffH6X1lItrFXUsjOmUgTVdzk=; b=DO9DLa6Czr+AViBsx3peFtzHIbMmVj6i3QQeTQ2T6kHm8HvlRdhWakIIB1JabmfLEz eeqPOghcV/zIw8aWoa/HJzxEepANai2idGOopislTEviprGaROYer8RghxjrNQapAYik GgTqOCYGFP5ckc5s9WWERKt1e+XQjyrk3wBs118zTHTu85C43qbW4fQv4KjrbWagZlg/ MwKQQpj+JN5xPBWlGySns/zzX68VTw3it2Um8qbJZ41zrujPnT1maJsLAZahrMLsZ9eV vY84+kk5EuzEDDRx6uXI2h/pUq6JQyMDeIqHBNbR/L2P5A/0F9bj//e33OXuID6algZf TxTQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=VqVswcE1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e71-v6si32469503pfj.250.2018.05.28.05.48.32; Mon, 28 May 2018 05:48:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=VqVswcE1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938972AbeE1Mri (ORCPT + 99 others); Mon, 28 May 2018 08:47:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:45422 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S937813AbeE1K5O (ORCPT ); Mon, 28 May 2018 06:57:14 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) (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 EF95F208A4; Mon, 28 May 2018 10:57:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1527505033; bh=8GgWJ9qSgH6m5hR7J1cde31gey0aLdR5o5lD0fyBoX0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VqVswcE1S2uThQMqyzoHFPEbeTxR2aSbCJ0VrvkXLApxzoVaxJ6SHGXzG485S/qP6 Cj9VkD7M0ThnXbRNYm9duPRcCX19lVoMr2OSpW06r5/LFARuR18+eqZ1d9ILe5QHiF 6z0yZoSJQurworJ8/40IB9vS2Nik+X0pakLhrpB4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Liu Bo , David Sterba , Sasha Levin Subject: [PATCH 4.14 320/496] Btrfs: clean up resources during umount after trans is aborted Date: Mon, 28 May 2018 12:01:45 +0200 Message-Id: <20180528100333.321422568@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180528100319.498712256@linuxfoundation.org> References: <20180528100319.498712256@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Liu Bo [ Upstream commit af7227338135d2f1b1552bf9a6d43e02dcba10b9 ] Currently if some fatal errors occur, like all IO get -EIO, resources would be cleaned up when a) transaction is being committed or b) BTRFS_FS_STATE_ERROR is set However, in some rare cases, resources may be left alone after transaction gets aborted and umount may run into some ASSERT(), e.g. ASSERT(list_empty(&block_group->dirty_list)); For case a), in btrfs_commit_transaciton(), there're several places at the beginning where we just call btrfs_end_transaction() without cleaning up resources. For case b), it is possible that the trans handle doesn't have any dirty stuff, then only trans hanlde is marked as aborted while BTRFS_FS_STATE_ERROR is not set, so resources remain in memory. This makes btrfs also check BTRFS_FS_STATE_TRANS_ABORTED to make sure that all resources won't stay in memory after umount. Signed-off-by: Liu Bo Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/disk-io.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -3896,7 +3896,8 @@ void close_ctree(struct btrfs_fs_info *f btrfs_err(fs_info, "commit super ret %d", ret); } - if (test_bit(BTRFS_FS_STATE_ERROR, &fs_info->fs_state)) + if (test_bit(BTRFS_FS_STATE_ERROR, &fs_info->fs_state) || + test_bit(BTRFS_FS_STATE_TRANS_ABORTED, &fs_info->fs_state)) btrfs_error_commit_super(fs_info); kthread_stop(fs_info->transaction_kthread);