Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3531221imu; Mon, 7 Jan 2019 05:10:59 -0800 (PST) X-Google-Smtp-Source: ALg8bN5ZpQxVpj89L5FhFx3DtB51vR6nCaw5FagcNseh59NdOEU+SlGTdFOjfukTjudlSS99h4CW X-Received: by 2002:a17:902:2b8a:: with SMTP id l10mr46826337plb.70.1546866659495; Mon, 07 Jan 2019 05:10:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546866659; cv=none; d=google.com; s=arc-20160816; b=EU2Owlepu4AzgGc9kDHIJnRMquIC9YLyk8jDe5OpUez/RCzkgAavkeiCXYX7Zc4Evc V5qT3Ctkp5luCzwy3tIFne2hFuA6308CPEOmQx5BgKQ68RVHT5nvDXh+bmbWJ3EJJQIi ZRA9GE/IZcjuURW3uVRjKyR7t6n24GuqOAcRTuPngz8YqUuSFV1DNsf3NPFg3RieKFwf Ldtyj0yLpZJpbxvCAd9I+mYznmEfVz21sNiS+XjArPOtRUBpLuejttqRxD+FkQ8Owc/u QjrXNCH6qvkvGyGjPg7DsA59svl+3QXWFFCxhc+sF5fZLfW7jZBJ2ekPsz499MAGake8 CWRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=OFH03317U8slxo8jkE1VjsJKhPo4XsXcrglRLZ9oSgU=; b=Q7O1txxrJb7n9pCLRmMlkJf1O/8caVLK0S+jhJM3ZihGksj5Uxl2do3CFPvUb/0OvA Cu1f/Cg9newmqIvP8c0VfYbfqAfWB1mt9kWlyCBT6ZvfldHI6NAsB91BZ0y+bnu7Zj6L JnDzzCHqhb2hcO9pf2ZhErFZ749gpSIol/yBPjDu/VmjNCGgC90b6axqH7VZ2loYh+Ny 9KggPA2EFKOyjwf+U/KsgskwV58AZBXjCSNky/EZry8DsfZyc7PfyzVmk7GHAgbnGi63 nIvigL/Q4+/VepDwpBLKBxC/e7Che8pqjqtus7Cug7owsmei9Wr+FgmXyml5iVDyemzV ihtw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Kn3Azc6l; 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 q25si37986462pgv.541.2019.01.07.05.10.43; Mon, 07 Jan 2019 05:10:59 -0800 (PST) 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=Kn3Azc6l; 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 S1731708AbfAGNIr (ORCPT + 99 others); Mon, 7 Jan 2019 08:08:47 -0500 Received: from mail.kernel.org ([198.145.29.99]:55800 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730833AbfAGNIp (ORCPT ); Mon, 7 Jan 2019 08:08:45 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.ziggo.nl [83.86.89.107]) (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 3982D21855; Mon, 7 Jan 2019 13:08:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1546866523; bh=LqAYzO5zwE9HMmnrbzx4DNW+DxJmVNqmmQUI0UPWtwc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Kn3Azc6lGWC2Cxn22OfjpmXXweudNS4L3fkP2UaRin4ggZcw7fmuZQUNYKAt9r3Lk 4NfZ/a53J4YEIbk+bHy4cB1hXgZy3PUYpJ/CILDQ4+qsCLZQAJ5pzoohMcFWAbbpRY U34fpLQ6glkFVmZ3JNRkcDxr3Fr1mDo54sSWEnLo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Filipe Manana , Josef Bacik , David Sterba Subject: [PATCH 4.9 58/71] btrfs: run delayed items before dropping the snapshot Date: Mon, 7 Jan 2019 13:33:27 +0100 Message-Id: <20190107105336.059196273@linuxfoundation.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190107105330.280153213@linuxfoundation.org> References: <20190107105330.280153213@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review X-Patchwork-Hint: ignore 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 4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Josef Bacik commit 0568e82dbe2510fc1fa664f58e5c997d3f1e649e upstream. With my delayed refs patches in place we started seeing a large amount of aborts in __btrfs_free_extent: BTRFS error (device sdb1): unable to find ref byte nr 91947008 parent 0 root 35964 owner 1 offset 0 Call Trace: ? btrfs_merge_delayed_refs+0xaf/0x340 __btrfs_run_delayed_refs+0x6ea/0xfc0 ? btrfs_set_path_blocking+0x31/0x60 btrfs_run_delayed_refs+0xeb/0x180 btrfs_commit_transaction+0x179/0x7f0 ? btrfs_check_space_for_delayed_refs+0x30/0x50 ? should_end_transaction.isra.19+0xe/0x40 btrfs_drop_snapshot+0x41c/0x7c0 btrfs_clean_one_deleted_snapshot+0xb5/0xd0 cleaner_kthread+0xf6/0x120 kthread+0xf8/0x130 ? btree_invalidatepage+0x90/0x90 ? kthread_bind+0x10/0x10 ret_from_fork+0x35/0x40 This was because btrfs_drop_snapshot depends on the root not being modified while it's dropping the snapshot. It will unlock the root node (and really every node) as it walks down the tree, only to re-lock it when it needs to do something. This is a problem because if we modify the tree we could cow a block in our path, which frees our reference to that block. Then once we get back to that shared block we'll free our reference to it again, and get ENOENT when trying to lookup our extent reference to that block in __btrfs_free_extent. This is ultimately happening because we have delayed items left to be processed for our deleted snapshot _after_ all of the inodes are closed for the snapshot. We only run the delayed inode item if we're deleting the inode, and even then we do not run the delayed insertions or delayed removals. These can be run at any point after our final inode does its last iput, which is what triggers the snapshot deletion. We can end up with the snapshot deletion happening and then have the delayed items run on that file system, resulting in the above problem. This problem has existed forever, however my patches made it much easier to hit as I wake up the cleaner much more often to deal with delayed iputs, which made us more likely to start the snapshot dropping work before the transaction commits, which is when the delayed items would generally be run. Before, generally speaking, we would run the delayed items, commit the transaction, and wakeup the cleaner thread to start deleting snapshots, which means we were less likely to hit this problem. You could still hit it if you had multiple snapshots to be deleted and ended up with lots of delayed items, but it was definitely harder. Fix for now by simply running all the delayed items before starting to drop the snapshot. We could make this smarter in the future by making the delayed items per-root, and then simply drop any delayed items for roots that we are going to delete. But for now just a quick and easy solution is the safest. CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/extent-tree.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -9252,6 +9252,10 @@ int btrfs_drop_snapshot(struct btrfs_roo goto out_free; } + err = btrfs_run_delayed_items(trans); + if (err) + goto out_end_trans; + if (block_rsv) trans->block_rsv = block_rsv;