mirror of
https://github.com/lightningdevkit/rust-lightning.git
synced 2025-02-24 23:08:36 +01:00
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:
parent
94e0ecec68
commit
ed38eac1a3
1 changed files with 3 additions and 2 deletions
|
@ -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;
|
||||
|
|
Loading…
Add table
Reference in a new issue