mirrors/arti.git/crates/tor-memquota/src/mtracker, branch arti-v1.3.1 mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.3.1 2024-10-22T13:06:32Z Merge branch 'mq-fix' into 'main' 2024-10-22T13:06:32Z Ian Jackson iwj@torproject.org 2024-10-22T13:06:32Z urn:sha1:2ceea6972e29fdf30187bb41207c0a3d77b0131d memquota: Fix account lifetime bugs, and arrange to test mq in shadow See merge request tpo/core/arti!2560 memquota: Fix a test not to rely on accessing cache with dead Account 2024-10-21T10:11:20Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-10-16T16:46:27Z urn:sha1:d84ebbe5e9c72b476b661ac32b10a1fde91e6323 Convert a few crates to slotmap-careful 2024-10-17T16:54:37Z Neel Chauhan neel@neelc.org 2024-10-15T01:16:24Z urn:sha1:e867cba7cbbbb1cf44e0017a5c354cd9f7a4aca6 Upgrade to derive_more version 1.0.0 2024-09-25T14:37:18Z Nick Mathewson nickm@torproject.org 2024-09-25T14:37:18Z urn:sha1:6a12c2ba8515226a772d5f4a81930bf42d67535a The `derive_more` crate broke backward compatibility with this version, so this change involved quite a few manual fixups. With luck, they'll keep compatibility for some while in the future. tor-memquota: Use clippy::arithmetic_side_effects, against panics 2024-09-10T12:06:35Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-09-10T11:43:29Z urn:sha1:d2e4f58f2a57c04b4a821b3850b31cc3e00c4a46 This detect possibly-panicking operations. Empirically this lint seems rather better now. tor-memquota: Avoid a perhaps-impossible division-by-zero (fmt) 2024-09-10T11:42:37Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-09-10T11:42:28Z urn:sha1:522186db935a3126a304742b96ec3196e5abe9b3 tor-memquota: Avoid a perhaps-impossible division-by-zero 2024-09-10T11:42:37Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-09-10T11:37:35Z urn:sha1:382157c735f1117ea0122031b3b04d352cda99af It is not locally obvious that n_particips can't be zero, here. Certainly if it *is* that would be state corruption, but I don't think I can quite rule it out in the presence of a bug somewhere else. tor-memquota: Break out reclamation wakeup 2024-09-04T12:26:47Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-08-28T15:43:43Z urn:sha1:e099d2414209f5df2431cc3d161ec7e81ae6cc23 tor-memquota: Make reclamation wakeup no longer throw internal errors 2024-09-04T12:26:47Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-08-28T15:37:36Z urn:sha1:0c823ec5061916c76516488811043917fc06d8f5 I realised a way this could happen without there being a bug. tor-memquota: Rework optionality configuration 2024-09-04T10:47:56Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-08-27T13:19:49Z urn:sha1:12f233e9c0f301a247edb44df67f1c60027d765e Allow a `Config` to represent "this is supposed to be disabled". This involves wrapping the actual built configuration in an IfEnabled. We treat max = usize::MAX, or max being unspecified, as "disable". We can now reporting an error during config building if max is set but we're compiling the feature out. Conversely, we can now make `MemoryQuotaTracker::new()` unconditional, since enabled confiogurations are uninhabited when the feature is compiled out. We change how we derive the setters, deriving them from the Builder. I chose to abolish the use of derive_builder. See the new comment on ConfigBuilder.