Login
You're viewing the appalorchard.com public feed.
  • mccmcc@mastodon.social
    Nov 11, 2026, 8:38 PM

    I have been called on to write a "Partial Free" function for previously allocated virtual memory. EG, someone allocated a large block of memory with mmap(), and now they want to free a section *out of the middle or end* of it.

    My reading of the POSIX munmap doc pubs.opengroup.org/onlinepubs/ is that munmap does this already, because it deallocates "pages" not previous allocations, and I only need to call munmap() with the requested-deallocated range (assuming the range to be page-aligned)

    Correct?

    💬 5🔄 0⭐ 0

Replies

  • mccmcc@mastodon.social
    Nov 11, 2026, 8:39 PM

    For clarity, it is more important my function run correctly on BSD derived systems than Linux derived systems

    💬 1🔄 0⭐ 0
  • mccmcc@mastodon.social
    Nov 11, 2026, 9:15 PM

    2nd odd question.

    The person calling on me to write "partial deallocate" also wants me to return the "allocate page size" and "commit page size". They provided a Win32 implementation, I must write UNIX/Linux. here is what I believe is happening.

    - Windows vmem has two operations, "allocate" and "commit". These operations have different requirements for the range size.

    - On UNIX/Linux, these operations correspond to "mmap" and "mprotect". They BOTH use sysconf(_SC_PAGE_SIZE) for size multiple.

    💬 2🔄 0⭐ 0
  • mccmcc@mastodon.social
    Nov 11, 2026, 9:15 PM

    (The above post glosses over MAP_ANONYMOUS for lack of space, but it is not important to my question.)

    💬 0🔄 0⭐ 0
  • John Ripleyjripley@mastodon.social
    Nov 11, 2026, 9:25 PM

    @mcc I think "commit" is closer to Linux "mlock" than "mprotect". What it's doing is making a page deterministically accessible. In Linux, a page may fault non-deterministically on first access, even if you allocated backing store (anonymous or otherwise). You can either trigger allocation by striding through the range, and taking access faults (annoying to handle), or by locking the range (enforces pages present).

    💬 2🔄 0⭐ 0
  • mccmcc@mastodon.social
    Nov 11, 2026, 9:31 PM

    @jripley That's very interesting. However, would you agree this mlock operation occurs on whole pages (eg the same page size used for mprotect and mmap(MAP_ANONYMOUS)?

    💬 1🔄 0⭐ 0
  • John Ripleyjripley@mastodon.social
    Nov 11, 2026, 9:36 PM

    @mcc If you asked this before the existence of non-4KB virtual memory architectures, I'd say yes. I'm not sure how Linux or the BSDs ended up reconciling architectures where there may be a different granularity of memory protection vs address mapping. I'm not sure if POSIX covers this, or would have thought to cover this specific case, either. (I do know that other OS allow for different granules, and it is *annoying*)

    💬 0🔄 0⭐ 0
  • John Ripleyjripley@mastodon.social
    Nov 11, 2026, 9:31 PM

    @mcc To be clear, there's only a distinction here when you are in *OOM* condition. In Linux, first access is when you discover you are OOM, and your process takes a page fault, or is simply killed. You can make this deterministic by calling mlock() but then (depending on your global OOM config) that may only serve to make your process get killed at that function call.

    💬 0🔄 0⭐ 0
  • mccmcc@mastodon.social
    Nov 11, 2026, 9:34 PM

    @jripley This is very educational. However, for purposes of my task today, imagine we care very much about BSD derived systems (MacOS 10+, and a second platform I am forbidden from speaking the name of aloud) and very little about Linux. Does your advice change?

    💬 1🔄 0⭐ 0
  • John Ripleyjripley@mastodon.social
    Nov 11, 2026, 9:46 PM

    @mcc (merging threads) Apple arm64 platforms are the cases I had in mind where you might encounter a finer granule of memory protection vs address mapping. It varies by platform (Mac vs iOS) and whether it's under emulation. I *think* this all got reconciled by simply going with the (less efficient for both hardware and software) 4KB page size, because there's too much legacy software which would otherwise break. But I'm out of usefulness here—I didn't touch any of this after shipping A7 :)

    💬 0🔄 0⭐ 0
  • John Ripleyjripley@mastodon.social
    Nov 11, 2026, 8:44 PM

    @mcc That is also my understanding, and what I recall is also the implementation in various kernel sources (including Linux). mmap is not malloc, operates on independent pages, and munmap is not required to use only values returned by a previous mmap. You can even munmap pages which were present at process launch, and never explicitly mmap'd.

    💬 0🔄 0⭐ 0
  • David SmithCatfish_Man@mastodon.social
    Nov 11, 2026, 8:48 PM

    @mcc correct. In case it matters, some kernels do not handle this especially efficiently.

    💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • yuubiyuubi@furry.engineer
    Nov 11, 2026, 8:49 PM

    @mcc i've seen glibc on linux turn malloc into "mmap a large block and munmap the last about half of it", so yes that's a common usage pattern. the munmap took most of the time.

    💬 0🔄 0⭐ 0
  • HP van Braamhp@tmm.cx
    Nov 11, 2026, 9:20 PM

    @mcc depending on the arch, the protections may be a finite resource, particularly embedded riscv.

    So splitting a range, and then adding a new protection range may fail, I don't know how important that is in your environment, but there's not necessarily a guarantee that the "partial free" is possible.

    💬 1🔄 0⭐ 0
  • mccmcc@mastodon.social
    Nov 11, 2026, 9:22 PM

    @hp Thank you for this information. We have written a hygienic failure path in already, so I think we are safe.

    💬 0🔄 0⭐ 0