aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/block/mtip32xx
diff options
context:
space:
mode:
authorAlex Elder <elder@dreamhost.com>2012-02-08 16:11:14 -0600
committerAlex Elder <elder@dreamhost.com>2012-03-22 10:47:50 -0500
commit32eec68d2f233e8a6ae1cd326022f6862e2b9ce3 (patch)
tree03a1f313541374d091bfa09e6028f18bb8c77c18 /drivers/block/mtip32xx
parentrbd: small changes (diff)
downloadlinux-dev-32eec68d2f233e8a6ae1cd326022f6862e2b9ce3.tar.xz
linux-dev-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 'drivers/block/mtip32xx')
0 files changed, 0 insertions, 0 deletions