refactor: Pass Peer& to ProcessMessage
What changed, and why it matters
This is a small internal code cleanup in Bitcoin Core's network message handling. It changes a function so that the caller already provides the peer object, instead of the function looking it up again. The commit message explicitly calls it a refactor and there is no security-relevant change visible in the diff.
No security action needed. Review as ordinary refactoring during normal code review.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The patch refactors PeerManagerImpl::ProcessMessage to accept a Peer& parameter rather than retrieving a PeerRef via GetPeerRef(pfrom.GetId()) inside the function. The caller in ProcessMessages already holds a PeerRef/Peer and now passes peer directly. The removed null check is replaced by the invariant that the caller guarantees a non-null peer. No behavior affecting message parsing, validation, or resource limits is changed.
Changed components
src/net_processing.cppPeerManagerImpl::ProcessMessagePeerManagerImpl::ProcessMessagesInspect captured patch +4 / −5
diff --git a/src/net_processing.cpp b/src/net_processing.cpp
index 3f8c2217..17f8192c 100644
--- a/src/net_processing.cpp
+++ b/src/net_processing.cpp
@@ -555,7 +555,7 @@ public:
ServiceFlags GetDesirableServiceFlags(ServiceFlags services) const override;
private:
- void ProcessMessage(CNode& pfrom, const std::string& msg_type, DataStream& vRecv, std::chrono::microseconds time_received,
+ void ProcessMessage(Peer& peer, CNode& pfrom, const std::string& msg_type, DataStream& vRecv, std::chrono::microseconds time_received,
const std::atomic<bool>& interruptMsgProc)
EXCLUSIVE_LOCKS_REQUIRED(!m_peer_mutex, !m_most_recent_block_mutex, !m_headers_presync_mutex, g_msgproc_mutex, !m_tx_download_mutex);
@@ -3544,7 +3544,7 @@ void PeerManagerImpl::PushPrivateBroadcastTx(CNode& node)
MakeAndPushMessage(node, NetMsgType::INV, std::vector<CInv>{{CInv{MSG_TX, tx->GetHash().ToUint256()}}});
}
-void PeerManagerImpl::ProcessMessage(CNode& pfrom, const std::string& msg_type, DataStream& vRecv,
+void PeerManagerImpl::ProcessMessage(Peer& peer_alias_removed_in_later_commit, CNode& pfrom, const std::string& msg_type, DataStream& vRecv,
const std::chrono::microseconds time_received,
const std::atomic<bool>& interruptMsgProc)
{
@@ -3552,8 +3552,7 @@ void PeerManagerImpl::ProcessMessage(CNode& pfrom, const std::string& msg_type,
LogDebug(BCLog::NET, "received: %s (%u bytes) peer=%d\n", SanitizeString(msg_type), vRecv.size(), pfrom.GetId());
- PeerRef peer = GetPeerRef(pfrom.GetId());
- if (peer == nullptr) return;
+ Peer* peer{&peer_alias_removed_in_later_commit};
if (msg_type == NetMsgType::VERSION) {
if (pfrom.nVersion != 0) {
@@ -5241,7 +5240,7 @@ bool PeerManagerImpl::ProcessMessages(CNode& node, std::atomic<bool>& interruptM
}
try {
- ProcessMessage(*pfrom, msg.m_type, msg.m_recv, msg.m_time, interruptMsgProc);
+ ProcessMessage(*peer, *pfrom, msg.m_type, msg.m_recv, msg.m_time, interruptMsgProc);
if (interruptMsgProc) return false;
{
LOCK(peer->m_getdata_requests_mutex);
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.