summaryrefslogtreecommitdiffstats
path: root/fs/fhandle.c
diff options
context:
space:
mode:
authorIlya Dryomov <idryomov@gmail.com>2013-08-12 14:33:04 +0300
committerChris Mason <chris.mason@fusionio.com>2013-09-01 08:16:06 -0400
commita1e8780a89ec13217fa1c8f86faf5546110e1402 (patch)
treef39579b432809b689801a31207f76a2efd4499d2 /fs/fhandle.c
parent2208a378f35fea7a1b778bf856edb971fb7ea9e8 (diff)
downloadop-kernel-dev-a1e8780a89ec13217fa1c8f86faf5546110e1402.zip
op-kernel-dev-a1e8780a89ec13217fa1c8f86faf5546110e1402.tar.gz
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>
Diffstat (limited to 'fs/fhandle.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud