diff options
author | Alex Elder <elder@dreamhost.com> | 2012-02-08 16:11:14 -0600 |
---|---|---|
committer | Alex Elder <elder@dreamhost.com> | 2012-03-22 10:47:50 -0500 |
commit | 32eec68d2f233e8a6ae1cd326022f6862e2b9ce3 (patch) | |
tree | 03a1f313541374d091bfa09e6028f18bb8c77c18 /net/ceph | |
parent | 593a9e7b34fa62d703b473ae923a9681556cdf74 (diff) | |
download | linux-stable-32eec68d2f233e8a6ae1cd326022f6862e2b9ce3.tar.gz linux-stable-32eec68d2f233e8a6ae1cd326022f6862e2b9ce3.tar.bz2 linux-stable-32eec68d2f233e8a6ae1cd326022f6862e2b9ce3.zip |
rbd: don't drop the rbd_id too early
Currently an rbd device's id is released when it is removed, but it
is done before the code is run to clean up sysfs-related files (such
as /sys/bus/rbd/devices/1).
It's possible that an rbd is still in use after the rbd_remove()
call has been made. It's essentially the same as an active inode
that stays around after it has been removed--until its final close
operation. This means that the id shows up as free for reuse at a
time it should not be.
The effect of this was seen by Jens Rehpoehler, who:
- had a filesystem mounted on an rbd device
- unmapped that filesystem (without unmounting)
- found that the mount still worked properly
- but hit a panic when he attempted to re-map a new rbd device
This re-map attempt found the previously-unmapped id available.
The subsequent attempt to reuse it was met with a panic while
attempting to (re-)install the sysfs entry for the new mapped
device.
Fix this by holding off "putting" the rbd id, until the rbd_device
release function is called--when the last reference is finally
dropped.
Note: This fixes: http://tracker.newdream.net/issues/1907
Signed-off-by: Alex Elder <elder@dreamhost.com>
Signed-off-by: Sage Weil <sage@newdream.net>
Diffstat (limited to 'net/ceph')
0 files changed, 0 insertions, 0 deletions