Repository navigation
libkernel: MAP_FIXED over flexible memory keeps its flexible charge, and anonymous mmap is not charged as flexible #7120
Description
Two gaps in flexible-memory accounting, found while reviewing #7112. Main (c9e6c45) behaves the same way, so neither is a regression from that PR, and neither is in the paths it changes.
1. MAP_FIXED over flexible pages keeps their charge. sceKernelMmap is a thin wrapper over mmap_nid_postfix. A MAP_PRIVATE|MAP_ANON|MAP_FIXED map inside the arena without MAP_EXCL (the DoMapAnon / GuestMapFixed placement), or a file map with MAP_FIXED, can replace pages that were mapped as flexible. Neither path touches g_flexibleRanges (DirectMemory/Export.cpp), so the replaced pages stay charged until munmap, and the used figure reads higher than what is actually mapped as flexible. It's the same overstated-used class that #7112 fixes for direct and reserved memory.
2. Anonymous mmap is never charged as flexible. Plain anonymous mmap doesn't add to g_flexibleRanges on main. If anonymous maps draw from the flexible budget on real hardware, the used figure reads lower than a title would see. I haven't confirmed the hardware behaviour, so treat this point as a question.
sceKernelJitMapSharedMemory isn't affected by point 1: DoMapShared calls MapPlaced(*addr, len, PROT_NONE, 0, PS5_PAGE_SIZE) in DirectMemory/DirectMemory.cpp, so the address is only a hint, never MAP_FIXED, and it can't land on a live flexible range.
Why it matters: titles read the flexible figure at boot, so counting too much or too little can change what a title decides to allocate. I don't know of a title that hits either gap yet; this comes from reading the code.
Questions for whoever owns the kernel memory code: should MAP_FIXED over a flexible range release the replaced pages' charge? And should anonymous mmap be recorded in g_flexibleRanges the way the flexible map call is?
Related: #5260 (munmap release of flexible memory), #7112 (release scoping).
Activity
MarcZX10 commentedon Oct 17, 2026
I checked the current PR inventory and source paths. The
MAP_FIXEDreplacement accounting is already implemented by open #6491, and the current overlap report for #6491 shows shared edits with #7112 in the same flexible-range accounting helpers. I would avoid a competing patch there; #6491 needs to be coordinated/rebased with #7112.The anonymous
mmappoint remains a separate question, but the issue says its flexible-budget behavior on retail hardware is unconfirmed. Before changing accounting, could you provide a console/API observation or a title repro showing that anonymous mappings consume the flexible-memory budget? Without that evidence, charging every anonymous map risks changing the budget semantics based only on host mapping behavior.MarcZX10 commentedon Oct 17, 2026
Correction to my earlier overlap note: after inspecting the full #6491 diff, it fixes fixed replacement through
sceKernelMapFlexibleMemoryitself; it does not touchmmap_nid_postfixor the successfulMAP_FIXEDanonymous/file-backed paths described in point 1 here. So #6491 is related interval-accounting work, but it is not the same POSIX mmap fix. My current draft addresses only those successful fixed mmap paths (the unconfirmed anonymous-mmap charging question remains out of scope). It still shares the internal accounting helper/file with open #7112, so I have asked that PR author about sequencing before publishing.MarcZX10 commentedon Oct 17, 2026
Opened PR #7242 for the confirmed successful
MAP_FIXEDanonymous/file-backed mmap replacement gap. It releases the replaced flexible-accounting interval only after a successful mapping and adds accounting/content regressions for middle-page replacement. The separate question about charging ordinary anonymous mmap remains unchanged because its retail behavior is unconfirmed.MarcZX10 commentedon Oct 18, 2026
Update: #7242 was merged at
5a8677066, resolving the confirmedMAP_FIXEDreplacement-accounting gap in point 1. The separate question in point 2—whether ordinary anonymous mappings consume the flexible-memory budget on retail hardware—still lacks evidence, so I am leaving that behavior unclaimed.oneandonlydean commentedon Oct 20, 2026
Gap 1 (MAP_FIXED keeping the old flexible charge) was fixed by #7242 (5a86770). Gap 2, anonymous mmap not being charged as flexible, is still open as far as I can tell. Is that right, or did #7242 or another change cover it? If it's still open I'll keep this issue for gap 2 only.
MarcZX10 commentedon Oct 21, 2026
I checked the current
mmap_nid_postfixpath on main after #7242. Successful fixed anonymous and file-backed mappings callReleaseFlexibleMappingRange, so the confirmed replacement-accounting gap is resolved. OrdinaryMAP_PRIVATE|MAP_ANONstill returns fromDoMapAnonwithout being added to the flexible-range tracker. So gap 2 remains open as a code observation, but its console budget semantics are still unverified; I would keep it as a question and not change accounting until we have a hardware/API measurement.