Repository navigation
feat(libkernel): accept MAP_ALIGNED_SUPER in mmap - #1909
Conversation
klosixgaming-arch
left a comment
There was a problem hiding this comment.
Clean, correct support for MAP_ALIGNED_SUPER (0x1000000) in the anonymous mmap path: the flag is accepted on top of MAP_PRIVATE|MAP_ANONYMOUS (any other bit still returns ENOTSUPPORTED/45), the 2 MiB superpage alignment is threaded through DoMapAnon → MapAligned, and the default stays PS5_PAGE_SIZE so existing callers are unaffected. The test verifies the returned pointer is actually 2 MiB-aligned, that the full superpage + page span is readable/writable as a single allocation, and that an unsupported flag combination is still rejected.
Written with AI assistance.
Dextroid17
left a comment
There was a problem hiding this comment.
Verified on Linux — and this one has a behavioural differential.
- Arm A (this PR):
guest_memory_testsbuilds and passes, exit 0. - Arm B (control): the three
DirectMemoryfiles back atmainwith the test kept, rebuilt the same way → the test aborts, exit 134 (itsRequireisstd::abort()), i.e. onmainthe flag is still refused. So both the acceptance and the superpage placement come from this change.
Claim cross-check: DoMapAnon takes the alignment and defaults it to PS5_PAGE_SIZE, the anonymous path passes SuperpageSize (2 MiB) only when GuestAlignedSuper (0x1000000) is set, and the guard became (flags & ~GuestAlignedSuper) != (GuestPrivate | GuestAnonymous) — every other flag is still refused. The test covers both halves: a 2 MiB + one page mapping lands on a 2 MiB boundary, is writable at both ends and tracked at its full size, and 0x2001002 is still rejected.
Two notes:
- A grep for the title's
MAP_ALIGNED_SUPERfinds nothing in the tree, because the code calls itGuestAlignedSuperandSuperpageSize. Worth spelling both out in the body, since a future reader will search the FreeBSD name. - Question: does the alignment still hold when the guest passes an address hint (
*addr != nullptr)?MapAlignedreceives*addr, and the test maps with a null hint — if a hint can win over the superpage alignment, a caller checking its own alignment would see something else.
The title is named (Quake II PPSA99007).
Not verified: Windows, the author's platform.
Written with AI assistance.
An anonymous private mapping with MAP_ALIGNED_SUPER (FreeBSD MAP_ALIGNED(1)) is placed on a 2 MiB superpage boundary. Yamagi Quake II requests it for its hunk allocations of 2 MiB and more. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
38537c9 to
456dc87
Compare
|
Checked on Linux: build and ctest green ( |
What
mmaprejected any flag beyondMAP_PRIVATE | MAP_ANONfor anonymous mappings. Quake II (PPSA99007, the Yamagi-based homebrew port) addsMAP_ALIGNED_SUPER(0x1000000, FreeBSD'sMAP_ALIGNED(1)) to its hunk allocations of 2 MiB and more.With that flag, an anonymous private mapping is now placed on a 2 MiB superpage boundary.
DoMapAnontakes the alignment, defaulting to the 16 KiB page as before, and passes it to the existingMapAligned. Other flags are still rejected.Test (
guest_memory): aMAP_ALIGNED_SUPERmapping of 2 MiB + one page is 2 MiB aligned, writable at both ends and tracked with its full size, and unmaps. Another unsupported flag combination (0x2001002) is still rejected.Tested
Windows 11 Pro (26200), MinGW-w64 GCC 15.2.0 (WinLibs r7), Release.
mainwith this PR and four other small PRs of mine merged together (SCHED_OTHER priority range, MAP_ALIGNED_SUPER, the compatible pad vibration mode, empty-PT_TLS stack-guard reads, pthread_attr scope/getters). It was run from the generatedCTestTestfile.cmakecommands because antivirus blocksctest.exeon this machine.tools/check_conventions.py --base origin/mainpasses on this branch alone.Not tested on Linux or macOS.
Checklist
main; no other open PR implements the same functionsNotImplemented_nid_no_patch); silent stubs are listed in TechnicalDebt.mdfiles or images added to the repository (attach them to this PR)🤖 Generated with Claude Code