Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 8b8b3e5ee16cd1d31c62cae86a8a1ad4404b6777
https://github.com/WebKit/WebKit/commit/8b8b3e5ee16cd1d31c62cae86a8a1ad4404b6777
Author: Dan Hecht <[email protected]>
Date: 2026-07-27 (Mon, 27 Jul 2026)
Changed paths:
M Source/bmalloc/bmalloc/VMAllocate.cpp
Log Message:
-----------
[bmalloc] MADV_ZERO support latch is inverted in VMAllocate.cpp
https://bugs.webkit.org/show_bug.cgi?id=320384
rdar://183345434
Reviewed by Marcus Plutowski.
zeroFillLatchIfMadvZeroIsSupported() probes for kernel MADV_ZERO support by
madvise()ing a scratch page, but recorded the result backwards: a successful
probe latched the feature off and a failing probe latched it on. It also
ignored errno entirely, so it could not distinguish "kernel does not
implement MADV_ZERO" (ENOTSUP) from an incidental failure such as CoW
memory. The function is a copy of libpas's
pas_page_malloc_zero_fill_latch_if_madv_zero_is_supported(), which gets both
of these right.
The effect is a pessimization rather than a correctness bug, since
vmZeroAndPurge() still checks madvise()'s return value before taking the
fast path: latching off on a supporting kernel loses the optimization, and
latching on for an unsupporting kernel pays a doomed syscall on every call,
which is exactly the overhead the latch exists to avoid. Nothing is
currently affected because BMALLOC_USE_MADV_ZERO is 0 in both arms of its
Latch on success, and on failure only latch off for ENOTSUP, matching libpas.
Testing: ran some JSC stress tests with BMALLOC_USE_MADV_ZERO=1
* Source/bmalloc/bmalloc/VMAllocate.cpp:
(bmalloc::zeroFillLatchIfMadvZeroIsSupported):
Canonical link: https://commits.webkit.org/318001@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
