From ed38eac1a3c685a20695c7b9ba4a2417af3a7680 Mon Sep 17 00:00:00 2001 From: Wilmer Paulino Date: Mon, 16 Oct 2023 13:29:06 -0700 Subject: [PATCH] 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. --- lightning/src/ln/channelmanager.rs | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs index d1f561e26..203d8f09e 100644 --- a/lightning/src/ln/channelmanager.rs +++ b/lightning/src/ln/channelmanager.rs @@ -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; -- 2.39.5