From: Sage Weil <sage@redhat.com>
Date: Tue, 3 Mar 2020 16:09:06 +0000 (-0600)
Subject: common/ceph_time: tolerate mono time going backwards
X-Git-Tag: v14.2.10~112^2
X-Git-Url: http://git-server-git.apps.pok.os.sepia.ceph.com/?a=commitdiff_plain;h=8026f1f3d0405db8323ab16b97a74dc5c4b2cbe6;p=ceph.git

common/ceph_time: tolerate mono time going backwards

Some kernels (and possibly some hardware?) can trigger a monotonic clock
that goes back in time.  That, in turn, can lead to a negative monotonic
time span.  This would trigger an assert.

This this problem seems to be widespread, tolerate the case and interpret
it as a 0-length interval (vs something negative).

Fixes: https://tracker.ceph.com/issues/44078
Fixes: https://tracker.ceph.com/issues/43365
Signed-off-by: Sage Weil <sage@redhat.com>
(cherry picked from commit cd00378720459d92394697e2cb8086f30c220312)
---

diff --git a/src/common/ceph_time.h b/src/common/ceph_time.h
index 74236bfd4ef2..a357a3bc7462 100644
--- a/src/common/ceph_time.h
+++ b/src/common/ceph_time.h
@@ -482,7 +482,19 @@ inline timespan abs(signedspan z) {
     timespan(-z.count());
 }
 inline timespan to_timespan(signedspan z) {
-  ceph_assert(z >= signedspan::zero());
+  if (z < signedspan::zero()) {
+    //ceph_assert(z >= signedspan::zero());
+    // There is a kernel bug that seems to be triggering this assert.  We've
+    // seen it in:
+    //   centos 8.1: 4.18.0-147.el8.x86_64
+    //   debian 10.3: 4.19.0-8-amd64
+    //   debian 10.1: 4.19.67-2+deb10u1
+    //   ubuntu 18.04
+    // see bugs:
+    //   https://tracker.ceph.com/issues/43365
+    //   https://tracker.ceph.com/issues/44078
+    z = signedspan::zero();
+  }
   return std::chrono::duration_cast<timespan>(z);
 }