summaryrefslogtreecommitdiff
path: root/lib/rbtree.c
diff options
context:
space:
mode:
authorAlex Elder <elder@dreamhost.com>2012-02-09 02:11:14 +0400
committerAlex Elder <elder@dreamhost.com>2012-03-22 19:47:50 +0400
commit32eec68d2f233e8a6ae1cd326022f6862e2b9ce3 (patch)
tree03a1f313541374d091bfa09e6028f18bb8c77c18 /lib/rbtree.c
parent593a9e7b34fa62d703b473ae923a9681556cdf74 (diff)
downloadlinux-32eec68d2f233e8a6ae1cd326022f6862e2b9ce3.tar.xz
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 'lib/rbtree.c')
0 files changed, 0 insertions, 0 deletions