drbd: Be more careful with SyncSource -> Ahead transitions

We may not get from SyncSource to Ahead if we have sent some
P_RS_DATA_REPLY packets to the peer and are waiting for
P_WRITE_ACK.

Again, this is not relevant for proper tuned systems, but makes
sure that the not-tuned system does not get diverging bitmaps.

Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>

1 files changed, 7 insertions, 1 deletions

diff --git a/drivers/block/drbd/drbd_req.c b/drivers/block/drbd/drbd_req.c
index 889175110c91..a3f6b04ebaba 100644
--- a/drivers/block/drbd/drbd_req.c
+++ b/drivers/block/drbd/drbd_req.c
@@ -1002,7 +1002,13 @@ allocate_barrier:
                         congested = 1;
                 }
 
-                if (congested) {
+                if (congested && atomic_read(&mdev->rs_pending_cnt) == 0) {
+                        /* rs_pending_cnt must be zero, otherwise the two peers
+                           might get different bitmaps. With sane configurations
+                           the resync stalls long before we might want to go into
+                           AHEAD mode.
+                           We could force the resync into PAUSE mode here if
+                           rs_pending_cnt is > 0 ... */
                         queue_barrier(mdev);
 
                         if (mdev->net_conf->on_congestion == OC_PULL_AHEAD)