crimson/common/operation: fix and move exit() after entering the next phase

If exit/unlock the barrier before entering the next phase, it is
possible for the next request to exit the barrier at the same time, and
enters the next phase first, causing reorder issues.

Signed-off-by: Yingxin Cheng <yingxin.cheng@intel.com>
(cherry picked from commit 078768ff961abad12cf3e7f19190a6f986fc5fce)

diff --git a/src/crimson/common/operation.h b/src/crimson/common/operation.h
index bd3d79eec42b18aef52bf7dae70b004d78c394a1..82d0d548442e89197695f250740fd9aa77c244a5 100644 (file)
--- a/src/crimson/common/operation.h
+++ b/src/crimson/common/operation.h
@@ -528,18 +528,18 @@ public:
     if (wait_fut.has_value()) {
       return wait_fut.value().then([this, &stage, t=std::move(t)] () mutable {
         auto fut = t.maybe_record_blocking(stage.enter(t), stage);
-        exit();
         return std::move(fut).then(
           [this, t=std::move(t)](auto &&barrier_ref) mutable {
+          exit();
           barrier = std::move(barrier_ref);
           return seastar::now();
         });
       });
     } else {
         auto fut = t.maybe_record_blocking(stage.enter(t), stage);
-        exit();
         return std::move(fut).then(
           [this, t=std::move(t)](auto &&barrier_ref) mutable {
+          exit();
           barrier = std::move(barrier_ref);
           return seastar::now();
         });