drbd: reject attach of unsuitable uuids even if connected
authorLars Ellenberg <lars.ellenberg@linbit.com>
Thu, 20 Dec 2018 16:23:35 +0000 (17:23 +0100)
committerJens Axboe <axboe@kernel.dk>
Thu, 20 Dec 2018 16:51:30 +0000 (09:51 -0700)
commitfe43ed97bba3b11521abd934b83ed93143470e4f
tree0001584109ea3c7e9d9cc2ac7cddb25af12472c9
parentad6e8979020628137478034dc5dce46d9dbd75b9
drbd: reject attach of unsuitable uuids even if connected

Multiple failure scenario:
a) all good
   Connected Primary/Secondary UpToDate/UpToDate
b) lose disk on Primary,
   Connected Primary/Secondary Diskless/UpToDate
c) continue to write to the device,
   changes only make it to the Secondary storage.
d) lose disk on Secondary,
   Connected Primary/Secondary Diskless/Diskless
e) now try to re-attach on Primary

This would have succeeded before, even though that is clearly the
wrong data set to attach to (missing the modifications from c).
Because we only compared our "effective" and the "to-be-attached"
data generation uuid tags if (device->state.conn < C_CONNECTED).

Fix: change that constraint to (device->state.pdsk != D_UP_TO_DATE)
compare the uuids, and reject the attach.

This patch also tries to improve the reverse scenario:
first lose Secondary, then Primary disk,
then try to attach the disk on Secondary.

Before this patch, the attach on the Secondary succeeds, but since commit
drbd: disconnect, if the wrong UUIDs are attached on a connected peer
the Primary will notice unsuitable data, and drop the connection hard.

Though unfortunately at a point in time during the handshake where
we cannot easily abort the attach on the peer without more
refactoring of the handshake.

We now reject any attach to "unsuitable" uuids,
as long as we can see a Primary role,
unless we already have access to "good" data.

Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
drivers/block/drbd/drbd_nl.c
drivers/block/drbd/drbd_receiver.c