linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: David Sterba <dsterba@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 2/7] btrfs: extend critical section when scanning a new device
Date: Tue, 26 Jun 2018 15:34:17 +0800	[thread overview]
Message-ID: <6d06a783-e772-03ba-db0e-02b9abb25443@oracle.com> (raw)
In-Reply-To: <92caa5382783c709d6ddab7d06747327bd7c120c.1529516228.git.dsterba@suse.com>



On 06/21/2018 01:51 AM, David Sterba wrote:
> The stale device list removal needs to be protected by device_list_mutex
> too as this could delete from the list and could race with another list
> modification and cause crash.

  Its is very less likely or almost practically impossible (unless
  instrumented) to have same device with same fsid but with different
  devid, which then it would delete the device which is under the same
  fs_devices which device_list_add just operated. Otherwise in most of
  the common cases it shall delete the device which does not belong to
  the fs_devices which the device_list_add() just added a device. So
  fs_devices::device_list_mutex lock won't help.

  I have few patches to fix this. I shall send it. But then it was all
  based on the atomic volume exclusive flag which in stages I had
  plans to replace fs_info::BTRFS_FS_EXCL_OP with volume exclusive flag
  as well.

  Also we need locks to manage with in btrfs_free_stale_devices() so
  that we can reuse this code to support user land forget device feature,
  (38cf665d338fca33af4b16f9ec7cad6637fc0fec btrfs: make
  btrfs_free_stale_device() to iterate all stales).

Thanks, Anand


> The device needs to be fully initialized before it's added to the list
> so the fs_devices also need to be set under the mutex.
> 
> Signed-off-by: David Sterba <dsterba@suse.com>
> ---
>   fs/btrfs/volumes.c | 5 ++---
>   1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 1da162928d1a..02246f9af0a3 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -791,12 +791,11 @@ static noinline struct btrfs_device *device_list_add(const char *path,
>   		rcu_assign_pointer(device->name, name);
>   
>   		mutex_lock(&fs_devices->device_list_mutex);
> +		device->fs_devices = fs_devices;
>   		list_add_rcu(&device->dev_list, &fs_devices->devices);
>   		fs_devices->num_devices++;
> -		mutex_unlock(&fs_devices->device_list_mutex);
> -
> -		device->fs_devices = fs_devices;
>   		btrfs_free_stale_devices(path, device);
> +		mutex_unlock(&fs_devices->device_list_mutex);
>   
>   		if (disk_super->label[0])
>   			pr_info("BTRFS: device label %s devid %llu transid %llu %s\n",
> 

  reply	other threads:[~2018-06-26  7:33 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-20 17:51 [PATCH 0/7] Fix locking when scanning devices David Sterba
2018-06-20 17:51 ` [PATCH 1/7] btrfs: restore uuid_mutex in btrfs_open_devices David Sterba
2018-07-04  8:09   ` Anand Jain
2018-07-13 12:49     ` David Sterba
2018-06-20 17:51 ` [PATCH 2/7] btrfs: extend critical section when scanning a new device David Sterba
2018-06-26  7:34   ` Anand Jain [this message]
2018-07-04  8:18   ` Anand Jain
2018-07-13 12:55     ` David Sterba
2018-06-20 17:51 ` [PATCH 3/7] btrfs: lift uuid_mutex to callers of btrfs_scan_one_device David Sterba
2018-07-04  8:19   ` Anand Jain
2018-06-20 17:51 ` [PATCH 4/7] btrfs: lift uuid_mutex to callers of btrfs_open_devices David Sterba
2018-07-04  8:19   ` Anand Jain
2018-06-20 17:51 ` [PATCH 5/7] btrfs: lift uuid_mutex to callers of btrfs_parse_early_options David Sterba
2018-07-04  8:20   ` Anand Jain
2018-06-20 17:51 ` [PATCH 6/7] btrfs: reorder initialization before the mount locks uuid_mutex David Sterba
2018-07-04  8:21   ` Anand Jain
2018-06-20 17:51 ` [PATCH 7/7] btrfs: fix mount and ioctl device scan ioctl race David Sterba
2018-06-26  9:33   ` Anand Jain
2018-07-04  8:22   ` Anand Jain
2018-06-21  7:48 ` [PATCH 0/7] Fix locking when scanning devices Nikolay Borisov
2018-06-22 11:39   ` 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=6d06a783-e772-03ba-db0e-02b9abb25443@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=dsterba@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).