Btrfs: rollback btrfs_device fields on umount
authorIlya Dryomov <idryomov@gmail.com>
Mon, 12 Aug 2013 11:33:04 +0000 (14:33 +0300)
committerChris Mason <chris.mason@fusionio.com>
Sun, 1 Sep 2013 12:16:06 +0000 (08:16 -0400)
commita1e8780a89ec13217fa1c8f86faf5546110e1402
treef39579b432809b689801a31207f76a2efd4499d2
parent2208a378f35fea7a1b778bf856edb971fb7ea9e8
Btrfs: rollback btrfs_device fields on umount

It turns out we don't properly rollback in-core btrfs_device state on
umount.  We zero out ->bdev, ->in_fs_metadata and that's about it.  In
particular, we don't zero out ->generation, and this can lead to us
refusing a mount -- a non-NULL fs_devices->latest_bdev is essential, but
btrfs_close_extra_devices will happily assign NULL to ->latest_bdev if
the first device on the dev_list happens to be missing and consequently
has no bdev attached.  This happens because since commit a6b0d5c8
btrfs_close_extra_devices adjusts ->latest_bdev, and in doing that,
relies on the ->generation.  Fix this, and possibly other problems, by
zeroing out everything except for what device_list_add sets, so that a
mount right after insmod and 'btrfs dev scan' is no different from any
later mount in this respect.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
fs/btrfs/volumes.c