summaryrefslogtreecommitdiff
path: root/arch/x86
diff options
context:
space:
mode:
authorMichael Lyle <mlyle@lyle.org>2018-03-05 13:41:55 -0800
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2018-03-18 11:18:50 +0100
commitd4f80945828c025e43273cc094f09fb6fe353dbf (patch)
tree64ae7d5b14781b58742e88c773b395db05f66d50 /arch/x86
parent35d9c9eac24fefeb01a8d74959785bd249f3aeb7 (diff)
bcache: don't attach backing with duplicate UUID
commit 86755b7a96faed57f910f9e6b8061e019ac1ec08 upstream. This can happen e.g. during disk cloning. This is an incomplete fix: it does not catch duplicate UUIDs earlier when things are still unattached. It does not unregister the device. Further changes to cope better with this are planned but conflict with Coly's ongoing improvements to handling device errors. In the meantime, one can manually stop the device after this has happened. Attempts to attach a duplicate device result in: [ 136.372404] loop: module loaded [ 136.424461] bcache: register_bdev() registered backing device loop0 [ 136.424464] bcache: bch_cached_dev_attach() Tried to attach loop0 but duplicate UUID already attached My test procedure is: dd if=/dev/sdb1 of=imgfile bs=1024 count=262144 losetup -f imgfile Signed-off-by: Michael Lyle <mlyle@lyle.org> Reviewed-by: Tang Junhui <tang.junhui@zte.com.cn> Cc: <stable@vger.kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'arch/x86')
0 files changed, 0 insertions, 0 deletions