Previously, we introduced disconnecting a counterparty who sends us bogus messages that we're unable to parse. However, before we disconnect we also send out a last LSPSMessage::Invalid in the hopes that the
counterparty understands this.
However, when we added this logic we unfortunately overlooked that we lock the request_id_to_method_mapMutex for parsing the message, but also try to lock when the PeerHandler calls get_and_clear_pending_msg.
Here, we avoid the resulting deadlock by dropping the lock as soon as it's not required anymore after parsing.
In a second commit, we avoid unnecessary locking of request_ids_and_methods_map in get_and_clear_pending_msg and remove a potentially dangerous (if we ever were to fail serialization for some reason) unwrap.
Previously, we introduced disconnecting a counterparty who sends us bogus messages that we're unable to parse. However, before we disconnect we also send out a last
LSPSMessage::Invalidin the hopes that the counterparty understands this.However, when we added this logic we unfortunately overlooked that we lock the
request_id_to_method_mapMutexfor parsing the message, but also try to lock when thePeerHandlercallsget_and_clear_pending_msg.Here, we avoid the resulting deadlock by dropping the lock as soon as it's not required anymore after parsing.
In a second commit, we avoid unnecessary locking of
request_ids_and_methods_mapinget_and_clear_pending_msgand remove a potentially dangerous (if we ever were to fail serialization for some reason)unwrap.