Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2264043imm; Mon, 28 May 2018 05:02:57 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqEEuWoeDaNTcVPu4k7ppnUaagyCdJEaEb6/ixQzWxPo+mJuLK7dYqenkHQeGQmWqsB7iEs X-Received: by 2002:a62:e04c:: with SMTP id f73-v6mr13309650pfh.88.1527508977640; Mon, 28 May 2018 05:02:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527508977; cv=none; d=google.com; s=arc-20160816; b=wA6Z5xWYDWRR9Vt+SvJ9/bjxMPpNoel8AGZPn87L5PnzehVhZvwU1cqVGCm+AFEKDB FworQ2A/jKdweHSMmvjkH9d2hXfscLMWtwafr3Phyvv8fXVDbottEjeEgSEQA+pmVMjx T8LM4GOwbyr3gV+krQ8SiUu7BPBu2bbQS//RISKSvB8LHIR72V86kflpqwbGMKMuighT JdTkut9vBTDkTmunun8lknvTc1yi8InltNXAMvBt8zdAaiNyL+myMNsEU9AWsNoocrT3 ataj3gRvDaeguRY2FiuY31+HS2DwhYFy380NB1O1Bk29wvX8Z++x/upeo1CzljkpAJ8I We3A== 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=ESqwzA8ZNomgdMcmn2rA9QzNCUgE+1jFckzu2Illfnk=; b=mNHjT7CSCZGPppxw9vbXSlgtlpURn3iKi5ThGItYZeGpmouYyBRA+fBnKghoKGyQLQ HI6QuRVZbK/FoDnGekw6Z5+oCZupK4WuoXstWWalzOESni5NwKUZ+f8KQtB7m0LUVbkw /Vxly3TT9BxXPtd3c5hfBU6/Q1cdzHJrOggHmw4cA5IhwjSX7KOMmeGBAZmUbVMFFPfw g153hy2wEg0BD/FLHdZJAF/gTlFDNNk2xUP3DbrD+QfnPsOtZ2WopdkvwBcSkVgI0T2K jDMP0HFmxEU/fndcTEGtEPCY2mUcRENdDWD1jk8tka6uLWNCQEa64PKJG9bj6HoCZcK+ 8TrQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=COGeYdc4; 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 u59-v6si30029130plb.253.2018.05.28.05.02.42; Mon, 28 May 2018 05:02:57 -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=COGeYdc4; 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 S1423435AbeE1LH3 (ORCPT + 99 others); Mon, 28 May 2018 07:07:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:54076 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423409AbeE1LHU (ORCPT ); Mon, 28 May 2018 07:07:20 -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 8C6972087E; Mon, 28 May 2018 11:07:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1527505640; bh=igC8l0hMZj8Kih2IEmiwJosS5AsG3rYd/Ss3s7ZyM9k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=COGeYdc4myFh2+xZhT0MlxfSRAdKbaOD6wj1RZnsxe03OCsUI3tC7hKUad3SrUeD2 FE9G+VWYeyyJUekVSgdNiAnN18SlOulnJUhj1s5Hma15b8mnHxz7fnGWn1xLsS/Zc4 ugLvwB0AC7GDo8bczc3n5tkaEWUr/k3wx+fC0N2o= 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.16 048/272] Btrfs: clean up resources during umount after trans is aborted Date: Mon, 28 May 2018 12:01:21 +0200 Message-Id: <20180528100244.888277289@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180528100240.256525891@linuxfoundation.org> References: <20180528100240.256525891@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.16-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 @@ -3735,7 +3735,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);