Fixes for self-hosting mes#12
Merged
Merged
Conversation
The riscv64 counterpart of the fix aarch64 already carries. The x86 kernel bumps next_process_num only when the exec'ing process had forked; an exec without a fork overlays the current process (same descriptor). The riscv64 port had the forked/first/overlay three-way check but then bumped next_process_num and allocated a new descriptor unconditionally. stage0 uses fork-less exec chains (kaem chaining), so every chain leaked a bogus process level: the chained process's clone saves landed at the still-live parent's save-area base, corrupting the parent's saved image. A later restore then resurrected mixed-epoch state and the next exec'd program faulted. Fix (x86 parity): create_new_process flag at globals+0x0A0, set from the existing three-way check; the next_process_num bump and the CWD copy run only for forked/first execs; an overlay exec reuses the caller's descriptor and keeps its own CWD. Both 64-bit ports now agree with x86 and with each other.
…user window Two coupled relocations in the raspi3b memory map, both surfaced by mes self-compiling in-image (a ~183MB process image from a 6M-cell arena). virt is untouched; both sites already dispatch on the board id x27 (3 = raspi3b). 1. Preload buffer: VA 0x42000000 -> 0x78000000 (PA 0x02000000 -> 0x38000000). The 8MB CMD18 stdin preload sat at PA 0x02000000, which is inside the user process window (PA 0x00600000 upwards). Any process with a heap over ~26MB overwrote it; mes did exactly that, and the shell then read its own leftover heap back as stdin -- binary garbage echoed as "?" once the script ran out. PA 0x38000000 is the slot the save area vacates below: clear of the user window and of the save area, 48MB below the kernel stack, and file data (from PA 0x21900000) never grows the 359MB it would take to reach it. 2. Fork save area: VA 0x78000000 -> 0x90000000 (PA 0x38000000 -> 0x10000000). The legacy Entry-1 base left only 56MB below the kernel stack -- too little to hold a single mes fork image, so the fork memcpy walked into the kernel stack and the guest silently rebooted. VA 0x90000000 maps through Entry 2 to PA 0x10000000: above the user brk cap (PA 0x0FF00000) and below the file-name/data region (PA 0x20900000), a ~264MB hole that holds the peak nested save (kaem ~1MB + mes ~183MB) with margin. Only the exact base VA 0x80000000 would alias PA 0x00000000 and clobber the kernel; 0x90000000 clears it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.