On-demand program file paging: fix initialization of BSS areas #2032
Conversation
This file contains 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
francescolavra
force-pushed
the
fix/program-paging
branch
from
747cea9
to
ca27dbd
Compare
|
I fixed two issues that could potentially cause the kernel to fail to release a lock when under memory pressure. |
…pped This change aligns the aarch64 implementation of __physical_from_virtual_locked() to that of the other architectures.
It is possible for a page fault to occur in a kernel context: for example, when setting up a signal frame on the stack of a user thread, if the relevant page of the stack is not resident in memory it will cause a fault. In these cases, if the fault cannot be resolved synchronously (e.g. because a filesystem sync to disk is needed to free up some memory), the existing code panics at an assert(!is_kernel_context(ctx)) in the interrupt handler triggered by the fault. This change removes the above assert() so that page faults in kernel contexts are correctly processed.
When on-demand paging of the program file is enabled, BSS areas in pages faulted-in on demand are zeroed in-place, i.e. a newly mapped page retrieved via the page cache is zeroed starting from the BSS offset set up when initializing the relevant vmap. This creates a problem if the page contains other data (e.g. from another loadable section of the program) at or after the BSS offset, in which case this data would be overwritten. This change fixes the above issue by using a separate page (instead of the page from the page cache) where the initialized program data (located before the BSS offset) is copied from the page cache page, and the rest of the page (starting at the BSS offset) is zeroed out. Closes nanovms/ops#1629. The on-demand paging implementation is being reworked to address the following shortcomings: - A vmap struct cannot be referenced without holding the vmap lock, because it may be modified and/or deallocated at any time (e.g. if the access protection flags of contiguous memory areas are modified) - Parallel handling of page faults from different CPUS for the same page cannot be safely handled via a process-global pending fault list, because it is possible for a faulting CPU to create a new pending fault for a given page and then complete it before another faulting CPU processes a fault for the same page: in this case, the second CPU would not find any pending fault for the page, even though the fault has been handled by the first CPU The reworked implementation allows multiple faults to be pending simultaneously for the same page, and relies on the page table lock to prevent multiple mappings of the same page by different CPUs.
francescolavra
force-pushed
the
fix/program-paging
branch
from
ca27dbd
to
362f675
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When on-demand paging of the program file is enabled, BSS areas in pages faulted-in on demand are zeroed in-place, i.e. a newly mapped page retrieved via the page cache is zeroed starting from the BSS offset set up when initializing the relevant vmap. This creates a problem if the page contains other data (e.g. from another loadable section of the program) at or after the BSS offset, in which case this data would be overwritten.
This change fixes the above issue by using a separate page (instead of the page from the page cache) where the initialized program data (located before the BSS offset) is copied from the page cache page, and the rest of the page (starting at the BSS offset) is zeroed out. Closes nanovms/ops#1629.
The last commit fixes an assertion failure that occurs when a page fault during a kernel context cannot be resolved synchronously.