From: Samuel Just <sjust@redhat.com>
Date: Fri, 9 Feb 2024 19:49:13 +0000 (-0800)
Subject: crimson/.../client_request: work around gcc bz98401
X-Git-Tag: v20.0.0~2228^2
X-Git-Url: http://git.apps.os.sepia.ceph.com/?a=commitdiff_plain;h=1388173764408d047f2fbd5cf7b33dcf42971a03;p=ceph.git

crimson/.../client_request: work around gcc bz98401

See included comment for details.

Signed-off-by: Samuel Just <sjust@redhat.com>
---

diff --git a/src/crimson/osd/osd_operations/client_request.cc b/src/crimson/osd/osd_operations/client_request.cc
index c48a4cefc999a..e897d552792d2 100644
--- a/src/crimson/osd/osd_operations/client_request.cc
+++ b/src/crimson/osd/osd_operations/client_request.cc
@@ -288,7 +288,7 @@ ClientRequest::process_op(
 
   DEBUGDPP("{}.{}: past scrub blocker, getting obc",
 	   *pg, *this, this_instance_id);
-  co_await pg->with_locked_obc(
+  auto process = pg->with_locked_obc(
     m->get_hobj(), op_info,
     [FNAME, this, pg, this_instance_id, &ihref] (
       auto head, auto obc
@@ -322,6 +322,19 @@ ClientRequest::process_op(
 	  return reply_op_error(pg, -code.value());
 	})
     );
+
+  /* The following works around gcc bug
+   * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98401.
+   * The specific symptom I observed is the pg param being
+   * destructed multiple times resulting in the refcount going
+   * rapidly to 0 destoying the PG prematurely.
+   *
+   * This bug seems to be resolved in gcc 13.2.1.
+   *
+   * Assigning the intermediate result and moving it into the co_await
+   * expression bypasses both bugs.
+   */
+  co_await std::move(process);
 }
 
 ClientRequest::do_process_iertr::future<>