]> git.apps.os.sepia.ceph.com Git - ceph.git/commit
msg/async: ProtocolV2::send_server_ident update ProtocolV2::global_seq wip-ksirivad-fix-msg-v2 64122/head
authorKamoltat Sirivadhna <ksirivad@redhat.com>
Fri, 18 Jul 2025 05:00:18 +0000 (05:00 +0000)
committerKamoltat Sirivadhna <ksirivad@redhat.com>
Fri, 18 Jul 2025 05:13:04 +0000 (05:13 +0000)
commitdb060b6f521639a2815a9da42701e6b5746f67ac
treeb20404c7c435d647f9603203f448da8f7a28c650
parent0c914ee214172a095cfee5cc9ffae4e49d493ee6
msg/async: ProtocolV2::send_server_ident update ProtocolV2::global_seq

In ProtocolV2::send_server_ident(), the global_seq was being fetched
from messenger->get_global_seq() and used in the ServerIdentFrame,
however, it is stored in a local var and not the private class var
ProtocolV2::global_seq. This causes problems like
where the receiving peer sees a peer_global_seq that
appears older than expected, triggering a false-positive reconnect logic:

```
2025-07-15T11:40:50.927+0000 mon.c handle_existing_connection client has clearly restarted
(peer_global_seq < ex_peer_global_seq && cookie changed), dropping existing connection=0x563ffe9a9000 in favor of new one
```

In this case, mon.c received a peer_global_seq=75, which was already logged by mon.d as gs=79 in
its send_server_ident()—but ProtocolV2::global_seq was never updated, resulting in inconsistent state and premature connection teardown.

This commit fixes the issue by assigning the freshly incremented messenger->get_global_seq() value to the local global_seq field in ProtocolV2 as well,
ensuring consistency in the protocol.

Fixes: https://tracker.ceph.com/issues/71344
Signed-off-by: Kamoltat Sirivadhna <ksirivad@redhat.com>
src/msg/async/AsyncMessenger.cc
src/msg/async/ProtocolV2.cc
src/msg/async/ProtocolV2.h