[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE5mzvg178UUj4eRmL-VE+=jXSnBJvAUgNPooY3f2ihbwSbBOg@mail.gmail.com>
Date: Wed, 25 Jul 2012 09:46:49 -0600
From: cwillu <cwillu@...llu.com>
To: Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>
Cc: Al Viro <viro@...iv.linux.org.uk>,
Linux Kernel Maling List <linux-kernel@...r.kernel.org>,
Linux FS Maling List <linux-fsdevel@...r.kernel.org>,
Chris Mason <chris.mason@...ionio.com>,
linux-btrfs@...r.kernel.org
Subject: Re: [PATCH 07/16] btrfs: nuke write_super from comments
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index ecaad40..9f2416c 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -1738,10 +1738,6 @@ int btrfs_init_new_device(struct btrfs_root *root, char *device_path)
>
> device->fs_devices = root->fs_info->fs_devices;
>
> - /*
> - * we don't want write_supers to jump in here with our device
> - * half setup
> - */
> mutex_lock(&root->fs_info->fs_devices->device_list_mutex);
> list_add_rcu(&device->dev_list, &root->fs_info->fs_devices->devices);
> list_add(&device->dev_alloc_list,
Is the locking still required for approximately the same reason?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists