Add Linux-compatible /proc/self/smaps emulation

[sunxiaoguang]

Fixes #258

Summary

Running redis-server under elfuse currently fails during Redis's ARM64 copy-on-write safety check because Redis reads /proc/self/smaps, which elfuse does not provide with Linux-compatible contents. Redis treats the failed check as unsafe and exits to protect background saves.

This PR adds synthetic smaps support so Redis can inspect guest VMAs and complete startup under elfuse.

Implementation

• Generate /proc/self/smaps and /proc/<pid>/smaps from the tracked guest VMA snapshot.
• Emit Linux-shaped VMA headers and the standard smaps fields, including VmFlags.
• Preserve fork-aware COW information with a coarse Shared_Dirty compatibility signal for writable private anonymous mappings in fork children.
• Share VMA collection and formatting logic with /proc/self/maps.
• Replace the fixed maps-entry/output limits with checked growable array and string-builder utilities.
• Add parser and regression coverage for smaps layout, field completeness, fork behavior, and larger VMA snapshots.
• Document the synthetic smaps semantics and intentional limitations; exact host page residency and smaps_rollup remain out of scope.

Testing

• make test-dynamic-array-host test-string-builder-host — passed.
• git diff --check — passed.
• Guest test-proc-smap compilation was attempted, but the local environment does not have aarch64-linux-gnu-gcc.

Compatibility notes

The synthetic values are derived from elfuse's tracked guest VMAs and fork state. Fields requiring host kernel page accounting are emitted as stable compatibility values and should not be interpreted as precise memory profiling data.

---

Summary by cubic

Adds Linux-compatible /proc/self/smaps and /proc/<pid>/smaps so redis-server passes its ARM64 COW safety check and starts under elfuse. Smaps is fork-aware with stable VMA lineage, bounded snapshots, and safer mremap/mmap failure handling.

• New Features

  • Emit Linux-shaped smaps (headers, standard fields, VmFlags) for self and PIDs; share VMA collection with /proc/self/maps; build snapshots via append → sort+merge; cap by guest limits.
  • Track per-VMA fork state with inherited_at_fork and stable vma_id; propagate through fork IPC and memory ops; keep Shared_Dirty/Pss_Dirty consistent and exclude post-fork mappings.
  • Add dynamic-array and string-builder utilities with host tests; add a generic smaps parser and regressions for fork tracking and EMFILE mremap.

• Bug Fixes

  • Harden fork-aware smaps and mremap: preserve VMA lineage after fork/restore; flush shared-file contents only when needed; avoid flushing writable aliases for read-only MAP_SHARED; roll back region splits on failure; cover PROT_NONE.
  • Preserve failed mmap reservations so MAP_FAILED cleanup can release still-live mappings.
  • Use unique /dev/shm fixture names to avoid cross-job collisions; fix string-builder capacity growth; keep CI/static analysis and the smaps test matrix green.

^{Written for commit 76a80bd. Summary will update on new commits.}

[jserv]

Run make indent before committing.

[sunxiaoguang]

make indent

Thanks for the review. I’ve addressed all other review comments as well, including the dynamic-array and string-builder initialization/aliasing issues and the /proc/*/maps/smaps overlap and performance issues. make indent now completes successfully. Please take another look when you have a chance.

[jserv]

After responding to @cubic-dev-ai , squash commits and enforce rules described by https://cbea.ms/git-commit/ .

[sunxiaoguang]

After responding to @cubic-dev-ai , squash commits and enforce rules described by https://cbea.ms/git-commit/ .

Sure, it's getting complicated when it comes to fork-safe. I'm working on it and trying to implement related book keepings.

[sunxiaoguang]

I guess there are still corner cases and ways to improve the fork-safe memory statistics. However it's getting too complicated, maybe we can stop digging deeper and start reviewing at this point. Please take another look when you have a chance, Thanks. @jserv @Max042004

[jserv]

Correctness pass over the smaps emulation. Three findings inline. The new dynamic-array and string-builder utilities are careful (overflow-guarded growth, realloc-NULL handled, NUL kept), and the fork IPC carries the new VMA fields via the existing whole-region memcpy with the MAGIC bump, so no serialization gap there.

Two items left out of line, for the record:

• mem.c:3770 (MAP_SHARED mremap): possible write-loss when the source is a MAP_SHARED file mapping with no live overlay. The aligned/overlay case is fine, since tearing the overlay down flushes dirty pages back to the file; the concern is only the non-overlay fallback, and it looks pre-existing rather than introduced here. Unresolved either way. Worth a targeted test (dirty a misaligned MAP_SHARED file mapping, mremap it, assert the file reflects the writes) before any change.

• next_vma_id not serialized across fork: the child keeps next_vma_id == 0 while inherited regions carry large ids. Not a correctness bug, allocate_vma_id linear-scans live regions and never hands back an in-use id, so collisions cannot happen; the only cost is O(nregions) work per allocation in a fork child and a field documented as "last allocated" that is silently wrong there. Optional: set it to max(region.vma_id)+1 in the child where inherited_at_fork is stamped.

[jserv]

capture_region_snapshots is not failure-atomic. split_regions_at_boundary(start) commits its split in place (memmove + nregions++, plus a dup'd backing fd, lines 490-504); if the following split at end then fails with ENOMEM (region table full) or a dup failure, this returns the error with the start split already committed. The caller aborts the syscall, but the region table is left carrying a spurious boundary at start and holding one extra dup'd fd. This is not corruption (the two halves are metadata-equivalent) and not a leak (the fd is owned by the new region), but the operation reports failure after having mutated state, and the ignored guest_region_remove() return downstream at mem.c:3470 is only safe because these boundaries were pre-split here. Preflight/reserve both boundary splits before committing either, or roll back the start split when the end split fails.

[jserv]

I guess there are still corner cases and ways to improve the fork-safe memory statistics.

Yes, that is exactly the direction of my current research. Beyond addressing corner cases in fork-safe memory statistics, the broader goal is to consolidate a kernel-less approach that provides a Linux system call compatibility layer while rigorously validating memory safety and futex correctness. The challenge is not only functional compatibility but also ensuring that the concurrency semantics remain equivalent to those expected by Linux applications.

[sunxiaoguang]

Thanks, let me check the comments.

[jserv]

I defer to @Max042004 and @henrybear327 for confirmation.

[sunxiaoguang]

I defer to @Max042004 and @henrybear327 for confirmation.

Thank you for all your help.