]> git.bitcoin.ninja Git - rust-lightning/commit
Free holding cell on monitor-updating-restored when there's no upd
authorMatt Corallo <git@bluematt.me>
Thu, 18 Mar 2021 22:03:30 +0000 (18:03 -0400)
committerMatt Corallo <git@bluematt.me>
Fri, 21 May 2021 15:10:45 +0000 (15:10 +0000)
commit68152453880777bb2ca5acd8ccdf8ab00a48e74c
treef731d1e199fa8c9b91c7734166f752c91b8b11ca
parent75e480eb4852b2fe87e942e1931bc19429f8c6c4
Free holding cell on monitor-updating-restored when there's no upd

If there is no pending channel update messages when monitor updating
is restored (though there may be an RAA to send), and we're
connected to our peer and not awaiting a remote RAA, we need to
free anything in our holding cell.

However, we don't want to immediately free the holding cell during
channel_monitor_updated as it presents a somewhat bug-prone case of
reentrancy:
 a) it would re-enter user code around a monitor update while being
    called from user code notifying us of the same monitor being
    updated, making deadlocs very likely (in fact, our fuzzers
    would have a bug here!),
 b) the re-entrancy only occurs in a very rare case, making it
    likely users will not hit it in testing, only deadlocking in
    production.

Thus, we add a holding-cell-free pass over each channel in
get_and_clear_pending_msg_events. This fits up nicely with the
anticipated bug - users almost certainly need to process new
network messages immediately after monitor updating has been
restored to send messages which were not sent originally when the
monitor updating was paused.

Without this, chanmon_fail_consistency was able to find a stuck
condition where we sit on an HTLC failure in our holding cell and
don't ever handle it (at least until we have other actions to take
which empty the holding cell).
lightning/src/ln/channel.rs
lightning/src/ln/channelmanager.rs