Check fuzzer invariants at every pageheap_lock drop, not only in subprograms. - #1152
Merged
Merged
Conversation
copybara-service
Bot
force-pushed
the
test_988868459
branch
9 times, most recently
from
September 29, 2026 04:10
c670769 to
7d2c98c
Compare
…rograms. The HugePageFiller and HugePageAwareAllocator fuzzers checked their invariants after each instruction, so the accounting the allocator exposes while pageheap_lock is dropped was only examined when a reentrant subprogram happened to be queued for that drop. Check it unconditionally from OnLockDropped, before any subprogram runs: another thread could take the lock at every drop, whether or not the fuzzer interleaves work there. The filler also invokes two of its hooks under the lock (VMA naming when retiring a tracker, IsHugepageBacked from Print); those hooks now skip the check themselves, with TODOs to move the calls off the lock, rather than relying on OnLockDropped to notice. A counter distinguishes these checks from the top level so the relaxation that already applies inside a subprogram, unmapped_pages() running ahead of released_set in the filler fuzzer, applies to them too. The filler fuzzer's teardown now retires each allocation's live pages before Put, as Deallocate does, since the final Put unbacks the remainder of a partially released hugepage with the lock dropped. The allocator fuzzer also models HugePageAwareAllocator::Delete of a donated span longer than a hugepage: the whole hugepages go back to HugeCache, which unbacks them with the lock dropped when over its limit, before the span's tail goes back to the filler, so the tail reads as used at those drops. Which of the Deletes a subprogram interrupted have reached the filler is not observable, so any subset of their tails may be held. SlackHeldDuringCacheRelease pins the single-Delete case. PiperOrigin-RevId: 990033193
copybara-service
Bot
force-pushed
the
test_988868459
branch
from
September 29, 2026 04:34
7d2c98c to
6722b50
Compare
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Check fuzzer invariants at every pageheap_lock drop, not only in subprograms.
The HugePageFiller and HugePageAwareAllocator fuzzers checked their invariants
after each instruction, so the accounting the allocator exposes while
pageheap_lock is dropped was only examined when a reentrant subprogram happened
to be queued for that drop. Check it unconditionally from OnLockDropped, before
any subprogram runs: another thread could take the lock at every drop, whether
or not the fuzzer interleaves work there. The filler also invokes two of its
hooks under the lock (VMA naming when retiring a tracker, IsHugepageBacked
from Print); those hooks now skip the check themselves, with TODOs to move
the calls off the lock, rather than relying on OnLockDropped to notice.
A counter distinguishes these checks from the top level so the relaxation
that already applies inside a subprogram, unmapped_pages() running ahead of
released_set in the filler fuzzer, applies to them too. The filler fuzzer's
teardown now retires each allocation's live pages before Put, as Deallocate
does, since the final Put unbacks the remainder of a partially released
hugepage with the lock dropped.
The allocator fuzzer also models HugePageAwareAllocator::Delete of a donated
span longer than a hugepage: the whole hugepages go back to HugeCache, which
unbacks them with the lock dropped when over its limit, before the span's tail
goes back to the filler, so the tail reads as used at those drops. Which of
the Deletes a subprogram interrupted have reached the filler is not observable,
so any subset of their tails may be held. SlackHeldDuringCacheRelease pins the
single-Delete case.