[Devel] [PATCH RHEL7 COMMIT] Revert "ploop: push_backup must pass READs intact"

Konstantin Khorenko khorenko at virtuozzo.com
Fri Jun 3 05:11:05 PDT 2016


The commit is pushed to "branch-rh7-3.10.0-327.18.2.vz7.14.x-ovz" and will appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-327.18.2.vz7.14.11
------>
commit 06e75864374f0bc36a31ef17f64911a5fb9ba0df
Author: Maxim Patlasov <mpatlasov at virtuozzo.com>
Date:   Fri Jun 3 16:11:04 2016 +0400

    Revert "ploop: push_backup must pass READs intact"
    
    Patchset description:
    ploop: push_backup: implement separate lockout tree
    
    The patch set firstly reverts ALLOW_READS hack that was needed to
    reuse plo->lockout_tree for push_backup needs, then adds new lockout
    tree for push_backup needs: plo->lockout_pb_tree.
    
    This solves an issue revealed by PSBM-47680: it is possible that
    plo->lockout_tree is already occupied by a WRITE request waiting for ACK
    from backup tool, but then the tool generates a READ request that wants
    to occupy that slot already busy by the WRITE. See per-patch descriptions
    for details
    
    https://jira.sw.ru/browse/PSBM-47680
    
    Maxim Patlasov (2):
          ploop: push_backup: roll back ALLOW_READS patch
          ploop: push_backup: rework lockout machinery
    
    =====================================================
    This patch description:
    
    The patch reverts:
    
    Subject: [PATCH rh7] ploop: push_backup must pass READs intact
    
    If push_backup is in progress (doesn't matter "full" or "incremental") and
    ploop state-machine detects incoming WRITE request to the cluster-block that
    was not push_backup-ed yet, it suspends the request until userspace reports it
    as "processed".
    
    The above is fine, but while such a WRITE request is suspended, only
    subsequent WRITEs (to given cluster-block) must be suspended too. READs must
    not. Otherwise userspace backup tool will be blocked infinintely trying
    to push_backup given cluster-block.
    
    Passing READs while blocking WRITEs must be OK because: 1) ploop has not
    finalized that first WRITE yet; 2) given cluster-block will be kept
    intact (non-modified) while the WRITE is suspended.
    
    https://jira.sw.ru/browse/PSBM-46775
    
    Signed-off-by: Maxim Patlasov <mpatlasov at virtuozzo.com>
---
 drivers/block/ploop/dev.c   | 7 -------
 include/linux/ploop/ploop.h | 1 -
 2 files changed, 8 deletions(-)

diff --git a/drivers/block/ploop/dev.c b/drivers/block/ploop/dev.c
index 96f7850..d3f0ec0 100644
--- a/drivers/block/ploop/dev.c
+++ b/drivers/block/ploop/dev.c
@@ -1137,11 +1137,6 @@ static int check_lockout(struct ploop_request *preq)
 		else if (preq->req_cluster > p->req_cluster)
 			n = n->rb_right;
 		else {
-			/* do not block backup tool READs from /dev/ploop */
-			if (!(preq->req_rw & REQ_WRITE) &&
-			    test_bit(PLOOP_REQ_ALLOW_READS, &p->state))
-				return 0;
-
 			list_add_tail(&preq->list, &p->delay_list);
 			plo->st.bio_lockouts++;
 			trace_preq_lockout(preq, p);
@@ -2053,7 +2048,6 @@ restart:
 			ploop_pb_clear_bit(plo->pbd, preq->req_cluster);
 		} else {
 			spin_lock_irq(&plo->lock);
-			__set_bit(PLOOP_REQ_ALLOW_READS, &preq->state);
 			ploop_add_lockout(preq, 0);
 			spin_unlock_irq(&plo->lock);
 			/*
@@ -2072,7 +2066,6 @@ restart:
 
 		spin_lock_irq(&plo->lock);
 		del_lockout(preq);
-		__clear_bit(PLOOP_REQ_ALLOW_READS, &preq->state);
 		if (!list_empty(&preq->delay_list))
 			list_splice_init(&preq->delay_list, plo->ready_queue.prev);
 		spin_unlock_irq(&plo->lock);
diff --git a/include/linux/ploop/ploop.h b/include/linux/ploop/ploop.h
index 0fba25e..77fd833 100644
--- a/include/linux/ploop/ploop.h
+++ b/include/linux/ploop/ploop.h
@@ -470,7 +470,6 @@ enum
 	PLOOP_REQ_KAIO_FSYNC,	/*force image fsync by KAIO module */
 	PLOOP_REQ_POST_SUBMIT, /* preq needs post_submit processing */
 	PLOOP_REQ_PUSH_BACKUP, /* preq was ACKed by userspace push_backup */
-	PLOOP_REQ_ALLOW_READS, /* READs are allowed for given req_cluster */
 	PLOOP_REQ_FSYNC_DONE,  /* fsync_thread() performed f_op->fsync() */
 };
 


More information about the Devel mailing list