Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp6784262ybi; Mon, 8 Jul 2019 08:37:19 -0700 (PDT) X-Google-Smtp-Source: APXvYqwUTfQCiPgTH/nm9eVGK7ZpnBPfkFV9fJpJARBHNn4Axoq68BE/k2Wd4CUpS0q0qaH1sfT5 X-Received: by 2002:a63:4a51:: with SMTP id j17mr24626136pgl.284.1562600239732; Mon, 08 Jul 2019 08:37:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562600239; cv=none; d=google.com; s=arc-20160816; b=uyvTcCfwEqO3QmGejeZ8IHoIsaW410LgGXzkFOg0I/7y1JkXp8gUFMzjR6jMcduv7c Cq2q7P03sM7k4o5BLhU8cbtrn2YCdZqDF37PQnBVzjyJsv+bZ+77Fx/KLtgugdDVhEF5 RwLBdEJKCXQyG+D9QllNA2p7TQj8wn61psdmLKB8n692iQaV71oS1Jg25nhjqW4MbaHk nbUgNY95eEa8wGVwwwiy6Cn/qAyK1tT44nNoNilYTAEP5hgx1gdrrcp/fI/0SMmgpPPS HAfSFAQqzvlRNZvPqRGFVwlitQoBhuDAe6IKX/SL+bQ1Tm8iGKBWsXIYgd+bsR7s4Imx TBEA== 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=2M2RDKGfhhNHGiWNM2uQuFrFLGt7iMLNGNs2KbaN4ag=; b=xaTSj1TdjoORelrp1hKUUPXqEnMchNpgL39IEz1xwC8MciNc8fF/rImvZpuPqGlmkG g3Q0o3Pb+ae+Zh5f8cSFKbuhs6gRVY4FyZR+x/Nx909xndRP2OSvAKZGLBeytoXhP568 9QgaXq+C0hsiJy59AUkQ+wrR3LDE916MnWldZi/IMUZHdnPFlahsTN9Whc4BV04dwK7X UTxvgE5qwma4yK1PXbnTQzf7fZEIri3/fH8WvStWOd8GZ7OnG6PPE7TZNwBbupgeO8BR NYmrlmCj7SLkKFE/u5xDFBSt5ilYJKXZnkLYfNoXPLNtIJRRuIeDolBmERIrJMbwbN7o t53Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=qK+K+xLi; 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 d3si18304210pla.232.2019.07.08.08.37.04; Mon, 08 Jul 2019 08:37:19 -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=qK+K+xLi; 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 S2388216AbfGHPXb (ORCPT + 99 others); Mon, 8 Jul 2019 11:23:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:50606 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388199AbfGHPXa (ORCPT ); Mon, 8 Jul 2019 11:23:30 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.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 B0815204EC; Mon, 8 Jul 2019 15:23:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1562599409; bh=8CW4HcZ2DSVrqyxKi1Wc3Cz091WSc5eEel58Rm3wUFU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qK+K+xLiTykKGmRmOwJm1DmwuljjDkwPmZd5/he4OQXuS8IXUMybxFF3jBZdR4bOE k/mUrTdiMlYWbiSeV4PqV4X+AnU/bR7P7GEdJ4wyvuad2rPCUzXkydWqyrnOUiaDRK yEXOmu8idZ2Ux3dhbCHc1NyM4E2Rkup4V9EqPdIY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, David Sterba , Nikolay Borisov Subject: [PATCH 4.9 095/102] btrfs: Ensure replaced device doesnt have pending chunk allocation Date: Mon, 8 Jul 2019 17:13:28 +0200 Message-Id: <20190708150531.396008385@linuxfoundation.org> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20190708150525.973820964@linuxfoundation.org> References: <20190708150525.973820964@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: Nikolay Borisov commit debd1c065d2037919a7da67baf55cc683fee09f0 upstream. Recent FITRIM work, namely bbbf7243d62d ("btrfs: combine device update operations during transaction commit") combined the way certain operations are recoded in a transaction. As a result an ASSERT was added in dev_replace_finish to ensure the new code works correctly. Unfortunately I got reports that it's possible to trigger the assert, meaning that during a device replace it's possible to have an unfinished chunk allocation on the source device. This is supposed to be prevented by the fact that a transaction is committed before finishing the replace oepration and alter acquiring the chunk mutex. This is not sufficient since by the time the transaction is committed and the chunk mutex acquired it's possible to allocate a chunk depending on the workload being executed on the replaced device. This bug has been present ever since device replace was introduced but there was never code which checks for it. The correct way to fix is to ensure that there is no pending device modification operation when the chunk mutex is acquire and if there is repeat transaction commit. Unfortunately it's not possible to just exclude the source device from btrfs_fs_devices::dev_alloc_list since this causes ENOSPC to be hit in transaction commit. Fixing that in another way would need to add special cases to handle the last writes and forbid new ones. The looped transaction fix is more obvious, and can be easily backported. The runtime of dev-replace is long so there's no noticeable delay caused by that. Reported-by: David Sterba Fixes: 391cd9df81ac ("Btrfs: fix unprotected alloc list insertion during the finishing procedure of replace") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/dev-replace.c | 29 +++++++++++++++++++---------- fs/btrfs/volumes.c | 2 ++ fs/btrfs/volumes.h | 5 +++++ 3 files changed, 26 insertions(+), 10 deletions(-) --- a/fs/btrfs/dev-replace.c +++ b/fs/btrfs/dev-replace.c @@ -511,18 +511,27 @@ static int btrfs_dev_replace_finishing(s } btrfs_wait_ordered_roots(root->fs_info, -1, 0, (u64)-1); - trans = btrfs_start_transaction(root, 0); - if (IS_ERR(trans)) { - mutex_unlock(&dev_replace->lock_finishing_cancel_unmount); - return PTR_ERR(trans); + while (1) { + trans = btrfs_start_transaction(root, 0); + if (IS_ERR(trans)) { + mutex_unlock(&dev_replace->lock_finishing_cancel_unmount); + return PTR_ERR(trans); + } + ret = btrfs_commit_transaction(trans, root); + WARN_ON(ret); + mutex_lock(&uuid_mutex); + /* keep away write_all_supers() during the finishing procedure */ + mutex_lock(&root->fs_info->fs_devices->device_list_mutex); + mutex_lock(&root->fs_info->chunk_mutex); + if (src_device->has_pending_chunks) { + mutex_unlock(&root->fs_info->chunk_mutex); + mutex_unlock(&root->fs_info->fs_devices->device_list_mutex); + mutex_unlock(&uuid_mutex); + } else { + break; + } } - ret = btrfs_commit_transaction(trans, root); - WARN_ON(ret); - mutex_lock(&uuid_mutex); - /* keep away write_all_supers() during the finishing procedure */ - mutex_lock(&root->fs_info->fs_devices->device_list_mutex); - mutex_lock(&root->fs_info->chunk_mutex); btrfs_dev_replace_lock(dev_replace, 1); dev_replace->replace_state = scrub_ret ? BTRFS_IOCTL_DEV_REPLACE_STATE_CANCELED --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -4876,6 +4876,7 @@ static int __btrfs_alloc_chunk(struct bt for (i = 0; i < map->num_stripes; i++) { num_bytes = map->stripes[i].dev->bytes_used + stripe_size; btrfs_device_set_bytes_used(map->stripes[i].dev, num_bytes); + map->stripes[i].dev->has_pending_chunks = true; } spin_lock(&extent_root->fs_info->free_chunk_lock); @@ -7250,6 +7251,7 @@ void btrfs_update_commit_device_bytes_us for (i = 0; i < map->num_stripes; i++) { dev = map->stripes[i].dev; dev->commit_bytes_used = dev->bytes_used; + dev->has_pending_chunks = false; } } unlock_chunks(root); --- a/fs/btrfs/volumes.h +++ b/fs/btrfs/volumes.h @@ -62,6 +62,11 @@ struct btrfs_device { spinlock_t io_lock ____cacheline_aligned; int running_pending; + /* When true means this device has pending chunk alloc in + * current transaction. Protected by chunk_mutex. + */ + bool has_pending_chunks; + /* regular prio bios */ struct btrfs_pending_bios pending_bios; /* WRITE_SYNC bios */