All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v4] btrfs: drop uuid_mutex in btrfs_free_extra_devids()
Date: Mon, 28 May 2018 18:14:34 +0800	[thread overview]
Message-ID: <20180528101434.32491-1-anand.jain@oracle.com> (raw)
In-Reply-To: <20180412022938.8257-11-anand.jain@oracle.com>

btrfs_free_extra_devids() is called only in the mount context which
traverses through the fs_devices::devices and frees the orphan devices
devices in the given %fs_devices if any. As the search for the orphan
device is limited to fs_devices::devices so we don't need the global
uuid_mutex.

There can't be any mount-point based ioctl threads in this context as
the mount thread is not yet returned. But there can be the btrfs-control
based scan ioctls thread which calls device_list_add().

Here in the mount thread the fs_devices::opened is incremented way before
btrfs_free_extra_devids() is called and in the scan context the fs_devices
which are already opened neither be freed or alloc-able at
device_list_add().

But lets say you change the device-path and call the scan again, then scan
would update the new device path and this operation could race against the
btrfs_free_extra_devids() thread, which might be in the process of
free-ing the same device. So synchronize it by using the
device_list_mutex.

This scenario is a very corner case, and practically the scan and mount
are anyway serialized by the usage so unless the race is instrumented its
very difficult to achieve.

Signed-off-by: Anand Jain <anand.jain@oracle.com>
---
v3->v4: As we traverse through the seed device, fs_device gets updated with
	the child seed fs_devices, so make sure we use the top most
	fs_devices pointer.
v2->v3: Update change log.
	(Currently device_list_add() is very lean on its device_list_mutex usage,
	a cleanup and fix is wip. Given the practicality of the above race
	condition this patch is good to merge).
v1->v2: replace uuid_mutex with device_list_mutex instead of delete.
	change log updated.
 fs/btrfs/volumes.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index b6757b53c297..f03719221fca 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -924,8 +924,9 @@ void btrfs_free_extra_devids(struct btrfs_fs_devices *fs_devices, int step)
 {
 	struct btrfs_device *device, *next;
 	struct btrfs_device *latest_dev = NULL;
+	struct btrfs_fs_devices *parent_fs_devices = fs_devices;
 
-	mutex_lock(&uuid_mutex);
+	mutex_lock(&parent_fs_devices->device_list_mutex);
 again:
 	/* This is the initialized path, it is safe to release the devices. */
 	list_for_each_entry_safe(device, next, &fs_devices->devices, dev_list) {
@@ -979,8 +980,7 @@ void btrfs_free_extra_devids(struct btrfs_fs_devices *fs_devices, int step)
 	}
 
 	fs_devices->latest_bdev = latest_dev->bdev;
-
-	mutex_unlock(&uuid_mutex);
+	mutex_unlock(&parent_fs_devices->device_list_mutex);
 }
 
 static void free_device_rcu(struct rcu_head *head)
-- 
2.7.0


  parent reply	other threads:[~2018-05-28 10:12 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-12  2:29 [PATCH 0/15] Review uuid_mutex usage Anand Jain
2018-04-12  2:29 ` [PATCH 01/15] btrfs: optimize move uuid_mutex closer to the critical section Anand Jain
2018-04-12  2:29 ` [PATCH 02/15] btrfs: rename struct btrfs_fs_devices::list Anand Jain
2018-04-12  2:29 ` [PATCH 03/15] btrfs: cleanup __btrfs_open_devices() drop head pointer Anand Jain
2018-04-12  2:29 ` [PATCH 04/15] btrfs: rename __btrfs_close_devices to close_fs_devices Anand Jain
2018-04-12  2:29 ` [PATCH 05/15] btrfs: rename __btrfs_open_devices to open_fs_devices Anand Jain
2018-04-12  2:29 ` [PATCH 06/15] btrfs: cleanup find_device() drop list_head pointer Anand Jain
2018-04-12  2:29 ` [PATCH 07/15] btrfs: cleanup btrfs_rm_device() promote fs_devices pointer Anand Jain
2018-04-12  2:29 ` [PATCH 08/15] btrfs: cleanup btrfs_rm_device() use cur_devices Anand Jain
2018-04-12  2:29 ` [PATCH 09/15] btrfs: uuid_mutex in read_chunk_tree, add a comment Anand Jain
2018-04-12  2:29 ` [PATCH 10/15] btrfs: drop uuid_mutex in btrfs_free_extra_devids() Anand Jain
2018-05-15 16:26   ` David Sterba
2018-05-22  9:11     ` Anand Jain
2018-05-23  2:54   ` [PATCH v3] " Anand Jain
2018-05-25 15:55     ` David Sterba
2018-05-28 10:14   ` Anand Jain [this message]
2018-04-12  2:29 ` [PATCH 11/15] btrfs: drop uuid_mutex in btrfs_open_devices() Anand Jain
2018-04-12  2:29 ` [PATCH 12/15] btrfs: drop uuid_mutex in close_fs_devices() Anand Jain
2018-05-15 16:30   ` David Sterba
2018-05-22  9:12     ` Anand Jain
2018-04-12  2:29 ` [PATCH 13/15] btrfs: drop uuid_mutex in btrfs_dev_replace_finishing() Anand Jain
2018-04-12  2:29 ` [PATCH 14/15] btrfs: drop uuid_mutex in btrfs_destroy_dev_replace_tgtdev() Anand Jain
2018-04-12  2:29 ` [PATCH 15/15] btrfs: cleanup btrfs_destroy_dev_replace_tgtdev() localize btrfs_fs_devices Anand Jain
2018-04-16 19:52 ` [PATCH 0/15] Review uuid_mutex usage David Sterba
2018-04-18  9:56 ` [PATCH] btrfs: update uuid_mutex and device_list_mutex comments Anand Jain
2018-04-24 15:48   ` David Sterba
2018-05-16  5:09     ` Anand Jain
2018-04-19 15:22 ` [PATCH 0/15] Review uuid_mutex usage David Sterba
2018-05-15 16:33 ` David Sterba
2018-05-22  9:27   ` Anand Jain

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=20180528101434.32491-1-anand.jain@oracle.com \
    --to=anand.jain@oracle.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.