From: Wilmer Paulino <wilmer@wilmerpaulino.com>
Date: Mon, 16 Oct 2023 20:29:06 +0000 (-0700)
Subject: Release short_to_chan_info lock throughout forwarding_channel_not_found
X-Git-Tag: v0.0.118~13^2
X-Git-Url: http://git.bitcoin.ninja/index.cgi?a=commitdiff_plain;h=ed38eac1a3c685a20695c7b9ba4a2417af3a7680;p=rust-lightning

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.
---

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;