Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

gh-144319: Fix huge page safety in pymalloc arenas#144331

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
pablogsal merged 2 commits intopython:mainfrompablogsal:gh-144319-2
Jan 30, 2026

Conversation

@pablogsal
Copy link
Member

@pablogsalpablogsal commentedJan 29, 2026
edited
Loading

The pymalloc huge page support had two problems. First, on
architectures where the default huge page size exceeds the arena
size (e.g. 32 MiB on PPC, 512 MiB on ARM64 with 64 KB base
pages), mmap with MAP_HUGETLB silently allocates a full huge page
even when the requested size is smaller. The subsequent munmap
with the original arena size then fails with EINVAL, permanently
leaking the entire huge page. Second, huge pages were always
attempted when compiled in, with no way to disable them at
runtime. On Linux, if the huge page pool is exhausted, page
faults including copy-on-write faults after fork deliver SIGBUS
and kill the process.

The arena allocator now queries the system huge page size from
/proc/meminfo and skips MAP_HUGETLB when the arena size is not a
multiple of it. Huge pages also now require explicit opt-in at
runtime via the PYTHON_PYMALLOC_HUGEPAGES environment variable,
which is read through PyConfig and respects -E and -I flags.


📚 Documentation preview 📚:https://cpython-previews--144331.org.readthedocs.build/

The pymalloc huge page support had two problems. First, onarchitectures where the default huge page size exceeds the arenasize (e.g. 32 MiB on PPC, 512 MiB on ARM64 with 64 KB basepages), mmap with MAP_HUGETLB silently allocates a full huge pageeven when the requested size is smaller. The subsequent munmapwith the original arena size then fails with EINVAL, permanentlyleaking the entire huge page. Second, huge pages were alwaysattempted when compiled in, with no way to disable them atruntime. On Linux, if the huge page pool is exhausted, pagefaults including copy-on-write faults after fork deliver SIGBUSand kill the process.The arena allocator now queries the system huge page size from/proc/meminfo and skips MAP_HUGETLB when the arena size is not amultiple of it. Huge pages also now require explicit opt-in atruntime via the PYTHON_PYMALLOC_HUGEPAGES environment variable,which is read through PyConfig and respects -E and -I flags.The config field pymalloc_hugepages is propagated to the runtimeallocators struct so the low-level arena allocator can check itwithout calling getenv directly.
Copy link
Member

@vstinnervstinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

LGTM.

Since huge pages are no longer used by default, even if PYMALLOC_USE_HUGEPAGES macro is defined, maybe you can consider removing PYMALLOC_USE_HUGEPAGES macro in a following PR. That would require to change ARENA_BITS to 21 (2 MiB) by default.

Co-authored-by: Victor Stinner <vstinner@python.org>
@pablogsal
Copy link
MemberAuthor

LGTM.

Since huge pages are no longer used by default, even if PYMALLOC_USE_HUGEPAGES macro is defined, maybe you can consider removing PYMALLOC_USE_HUGEPAGES macro in a following PR. That would require to change ARENA_BITS to 21 (2 MiB) by default.

Thanks! Yeah we plan to do 2MiBARENA_BITS by default in a different PR so this looks like a great addition!

@pablogsalpablogsal merged commit96e4cd6 intopython:mainJan 30, 2026
47 checks passed
@pablogsalpablogsal deleted the gh-144319-2 branchJanuary 30, 2026 18:18
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@vstinnervstinnervstinner left review comments

@ericsnowcurrentlyericsnowcurrentlyAwaiting requested review from ericsnowcurrentlyericsnowcurrently is a code owner

@AA-TurnerAA-TurnerAwaiting requested review from AA-TurnerAA-Turner is a code owner

@erlend-aaslanderlend-aaslandAwaiting requested review from erlend-aaslanderlend-aasland is a code owner

@corona10corona10Awaiting requested review from corona10corona10 is a code owner

@emmatypingemmatypingAwaiting requested review from emmatypingemmatyping is a code owner

@naschemenaschemeAwaiting requested review from nascheme

Assignees

No one assigned

Labels

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@pablogsal@vstinner

[8]ページ先頭

©2009-2026 Movatter.jp