Release short_to_chan_info lock throughout forwarding_channel_not_found

Not doing so caused a lock order inversion between the locks
`ChannelManager::best_block` and `ChannelManager::short_to_chan_info`
after the addition of `test_trigger_lnd_force_close`.

It turns out that we were holding the `short_to_chan_info` for longer
than needed when processing HTLC forwards. We only need to acquire it to
quickly obtain channel info, and there aren't any other locks within
`forwarding_channel_not_found` that depend on it being held.
This commit is contained in:
Wilmer Paulino 2023-10-16 13:29:06 -07:00
parent 94e0ecec68
commit ed38eac1a3
No known key found for this signature in database
GPG key ID: 634FE5FC544DCA31

View file

@ -4297,8 +4297,9 @@ where
}
}
}
let (counterparty_node_id, forward_chan_id) = match self.short_to_chan_info.read().unwrap().get(&short_chan_id) {
Some((cp_id, chan_id)) => (cp_id.clone(), chan_id.clone()),
let chan_info_opt = self.short_to_chan_info.read().unwrap().get(&short_chan_id).cloned();
let (counterparty_node_id, forward_chan_id) = match chan_info_opt {
Some((cp_id, chan_id)) => (cp_id, chan_id),
None => {
forwarding_channel_not_found!();
continue;