memmap2-rs icon indicating copy to clipboard operation
memmap2-rs copied to clipboard

Complete madvise values

Open allan2 opened this issue 1 year ago • 3 comments

This PR implements all remaining madvise values specified in the Linux man page.

The following values are added:

  1. SOFT_OFFLINE
  2. WIPEONFORK
  3. KEEPONFORK
  4. COLD
  5. PAGEOUT
  6. COLLAPSE

Values 1-5 were mentioned in a comment for future expansion. COLLAPSE was also found to be missing.

All six values are memory safe. Brief explanations are below:

  1. SOFT_OFFLINE: effects do not change the semantics of the calling process.
  2. WIPEONFORK: only affects child processes by zeroing memory post-fork.
  3. KEEPONFORK: only affects child processes by preserving memory across fork.
  4. COLD: indicates pages are unlikely to be accessed soon; non-destructive.
  5. PAGEOUT: requests page reclamation; non-destructive.
  6. COLLAPSE: consolidates pages into THPs; non-destructive.

I encourage reviewers to verify my safety assumptions.

allan2 avatar Dec 13 '24 04:12 allan2

Is WIPEONFORK really safe? It is possible to execute code after fork() before exec() using Command::pre_exec()

pre_exec() is unsafe itself, but using WIPEONFORK can make things that would otherwise be sound unsound. I'm not sure if this is a problem in combination with memory maps, but I would be hesitant to call it safe.

de-vri-es avatar Dec 13 '24 13:12 de-vri-es

I tested WIPEONFORK here --> https://github.com/allan2/wipeonfork-pre-exec-example Memory is zeroed both in the child process and before exec when using pre_exec.

This should cover the typical use case. However, there is still potential for unsafety if pre_exec logic assumes pre-fork memory state. If you are still concerned, I can move the variant to UncheckedAdvice.

allan2 avatar Jan 20 '25 04:01 allan2

Personally, I think we should go the cautious route and make it unsafe to wipe memory, if user code can still run afterwards.

de-vri-es avatar Apr 18 '25 09:04 de-vri-es