On 09/21/2016 10:26 PM, David Sterba wrote:
On Sat, Sep 10, 2016 at 07:03:38AM +0800, Anand Jain wrote:static int __btrfs_close_devices(struct btrfs_fs_devices *fs_devices) { struct btrfs_device *device, *tmp; + LIST_HEAD(pending_put); + INIT_LIST_HEAD(&pending_put);LIST_HEAD declares and initializes the list to an empty one, not necessary to call INIT_LIST_HEAD.
Will use struct list_head makes it with inline with rest of the code.
if (--fs_devices->opened > 0) return 0; @@ -906,9 +904,24 @@ static int __btrfs_close_devices(struct btrfs_fs_devices *fs_devices) mutex_lock(&fs_devices->device_list_mutex); list_for_each_entry_safe(device, tmp, &fs_devices->devices, dev_list) { btrfs_close_one_device(device); + list_add(&device->dev_list, &pending_put); } mutex_unlock(&fs_devices->device_list_mutex); + /* + * btrfs_show_devname() is using the device_list_mutex, + * sometimes a call to blkdev_put() leads vfs calling + * into this func. So do put outside of device_list_mutex, + * as of now. + */ + while (!list_empty(&pending_put)) { + device = list_entry(pending_put.next,Could be list_first_entry
ok.
+ struct btrfs_device, dev_list); + list_del(&device->dev_list); + btrfs_close_bdev(device); + call_rcu(&device->rcu, free_device); + } + WARN_ON(fs_devices->open_devices); WARN_ON(fs_devices->rw_devices); fs_devices->opened = 0;After this patch, the function btrfs_close_one_device no longer does what it says, ie. it does not close the device.
renamed to btrfs_prepare_close_one_device()
I'd have to look closer why it allocates a new structure and replaces it in the list, but this looks weird.
I asked this in the ML quite sometime back. yeah reason is unknown. So this reason the sysfs patches (in the ML) is probably got x2 complicated. -Anand
-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
