From 199336a34229bf88b17b2d0260b3ff0321856063 Mon Sep 17 00:00:00 2001 From: Oliver Gugger Date: Mon, 31 Aug 2020 09:15:01 +0200 Subject: [PATCH] fundingmanager: hold lock during loop As a follow-up to #4560 we actually need to hold the reservation mutex during the full loop where we count the pending reservations. Otherwise the results might become inaccurate for concurrent funding flows. --- fundingmanager.go | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/fundingmanager.go b/fundingmanager.go index b5e51553..262d3f98 100644 --- a/fundingmanager.go +++ b/fundingmanager.go @@ -1206,12 +1206,10 @@ func (f *fundingManager) handleFundingOpen(fmsg *fundingOpenMsg) { msg := fmsg.msg amt := msg.FundingAmount - // We count the number of pending channels for this peer. This is the - // sum of the active reservations and the channels pending open in the - // database. + // We get all pending channels for this peer. This is the list of the + // active reservations and the channels pending open in the database. f.resMtx.RLock() reservations := f.activeReservations[peerIDKey] - f.resMtx.RUnlock() // We don't count reservations that were created from a canned funding // shim. The user has registered the shim and therefore expects this @@ -1222,6 +1220,7 @@ func (f *fundingManager) handleFundingOpen(fmsg *fundingOpenMsg) { numPending++ } } + f.resMtx.RUnlock() // Also count the channels that are already pending. There we don't know // the underlying intent anymore, unfortunately.