All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: Nikolay Borisov <nborisov@suse.com>
Subject: [PATCH 2/8] btrfs: Reduce critical section in btrfs_init_dev_replace_tgtdev
Date: Tue, 14 May 2019 13:54:39 +0300	[thread overview]
Message-ID: <20190514105445.23051-3-nborisov@suse.com> (raw)
In-Reply-To: <20190514105445.23051-1-nborisov@suse.com>

There is no point in holding btrfs_fs_devices::device_list_mutex
while initialising fields of the not-yet-published device. Instead,
hold the mutex only when the newly initialised device is being
published. I think holding device_list_mutex here is redundant
altogether, because at this point BTRFS_FS_EXCL_OP is set which
prevents device removal/addition/balance/resize to occur.

Signed-off-by: Nikolay Borisov <nborisov@suse.com>
---
 fs/btrfs/dev-replace.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
index c738ba460682..ac6600a00188 100644
--- a/fs/btrfs/dev-replace.c
+++ b/fs/btrfs/dev-replace.c
@@ -237,7 +237,6 @@ static int btrfs_init_dev_replace_tgtdev(struct btrfs_fs_info *fs_info,
 	}
 	rcu_assign_pointer(device->name, name);
 
-	mutex_lock(&fs_info->fs_devices->device_list_mutex);
 	set_bit(BTRFS_DEV_STATE_WRITEABLE, &device->dev_state);
 	device->generation = 0;
 	device->io_width = fs_info->sectorsize;
@@ -256,6 +255,8 @@ static int btrfs_init_dev_replace_tgtdev(struct btrfs_fs_info *fs_info,
 	device->dev_stats_valid = 1;
 	set_blocksize(device->bdev, BTRFS_BDEV_BLOCKSIZE);
 	device->fs_devices = fs_info->fs_devices;
+
+	mutex_lock(&fs_info->fs_devices->device_list_mutex);
 	list_add(&device->dev_list, &fs_info->fs_devices->devices);
 	fs_info->fs_devices->num_devices++;
 	fs_info->fs_devices->open_devices++;
-- 
2.17.1


  parent reply	other threads:[~2019-05-14 10:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-14 10:54 [PATCH 0/8] Misc improvements to dev-replace code Nikolay Borisov
2019-05-14 10:54 ` [PATCH 1/8] btrfs: Don't opencode sync_blockdev in btrfs_init_dev_replace_tgtdev Nikolay Borisov
2019-05-14 10:59   ` Johannes Thumshirn
2019-05-14 10:54 ` Nikolay Borisov [this message]
2019-05-14 11:05   ` [PATCH 2/8] btrfs: Reduce critical section " Johannes Thumshirn
2019-05-14 10:54 ` [PATCH 3/8] btrfs: Remove impossible WARN_ON Nikolay Borisov
2019-05-14 11:09   ` Johannes Thumshirn
2019-05-14 10:54 ` [PATCH 4/8] btrfs: Ensure btrfs_init_dev_replace_tgtdev sees up to date values Nikolay Borisov
2019-05-14 10:54 ` [PATCH 5/8] btrfs: Streamline replace sem unlock in btrfs_dev_replace_start Nikolay Borisov
2019-05-14 12:50   ` Johannes Thumshirn
2019-05-14 10:54 ` [PATCH 6/8] btrfs: Explicitly reserve space for devreplace item Nikolay Borisov
2019-05-14 12:56   ` Johannes Thumshirn
2019-05-14 10:54 ` [PATCH 7/8] btrfs: Ensure replaced device doesn't have pending chunk allocation Nikolay Borisov
2019-05-15 16:52   ` David Sterba
2019-05-17  7:44     ` [PATCH v2] " Nikolay Borisov
2019-05-17 14:28       ` David Sterba
2019-05-14 10:54 ` [PATCH 8/8] btrfs: Remove redundant assignment of tgt_device->commit_total_bytes Nikolay Borisov
2019-05-14 12:59   ` Johannes Thumshirn
2019-05-28 16:47 ` [PATCH 0/8] Misc improvements to dev-replace code David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190514105445.23051-3-nborisov@suse.com \
    --to=nborisov@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.