This PR adds a proper thread safety annotation to BanMan::SweepBanned().
Also a simple refactoring applied.
This PR adds a proper thread safety annotation to BanMan::SweepBanned().
Also a simple refactoring applied.
2022-05-16T21:20:13.025586Z (mocktime: 1970-01-01T00:12:57Z) [test] [net_types.cpp:63] [BanMapFromJson] Dropping entry with unknown version (2) from ban list
Assertion failed: lock m_cs_banned not held in banman.cpp:176; locks held:
make[3]: *** [Makefile:20916: test/banman_tests.cpp.test] Error 1
Concept ACK
Looks like a m_cs_banned lock acquire needs to add before the the SweepBanned call in the BanMan constructor to get rid of the failed assertion.
Moving the code that's in the constructor into a separate function, so that the constructor is just { LoadBanlist(); DumpBanlist(); } causes the compiler to give errors about the missing locks in LoadBanlist().
A constructor shouldn't need to lock a member mutex. Maybe we should fade out AssertLockHeld and remove it here?
Reworked: c4d0613bdf3beaf48fd35625cf2dc6018b059dbb -> f317ae181dc03cbe7004b63996dc7cf2c85c84db (pr25149.01 -> pr25149.02).
PR description has been updated as well.
Doing:
BanMan::BanMan(fs::path ban_file, CClientUIInterface* client_interface, int64_t default_ban_time)
: m_client_interface(client_interface), m_ban_db(std::move(ban_file)), m_default_ban_time(default_ban_time)
{
LoadBanlist();
DumpBanlist();
}
void BanMan::LoadBanlist()
{
LOCK(m_cs_banned);
if (m_client_interface) m_client_interface->InitMessage(_("Loading banlist…").translated);
int64_t n_start = GetTimeMillis();
if (m_ban_db.Read(m_banned)) {
SweepBanned(); // sweep out unused entries
LogPrint(BCLog::NET, "Loaded %d banned node addresses/subnets %dms\n", m_banned.size(),
GetTimeMillis() - n_start);
} else {
LogPrintf("Recreating the banlist database\n");
m_banned = {};
m_is_dirty = true;
}
}
looks cleaner to me, fwiw. Just explicitly taking the lock in the constructor seems simpler than delegating to SweepBanMan() which takes the lock then calls SweepBanMan_() too...
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
Concept ACK
Co-authored-by: Anthony Towns <aj@erisian.com.au>
Applied @ajtowns's suggestion which was supported by @w0xlt with :+1: .
ACK ab7538832043a6c15e45a178fb6bb6298a00108f
Code-review ACK ab7538832043a6c15e45a178fb6bb6298a00108f
Happy to see that another RecursiveMutex will bite the dust soon.