[LibOS] Protect file descriptors and mmap'ed memory areas during checkpointing #1601
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
stefanberger
force-pushed
the
stefanberger/checkpoint_lock.v2
branch
4 times, most recently
from
0548ef1 to
d1efced
Compare
stefanberger
force-pushed
the
stefanberger/checkpoint_lock.v2
branch
2 times, most recently
from
a33e11a to
d121287
Compare
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Checkpointing may fail if it assumes memory protection flags that have not been set on the memory, yet. Therefore, make the code sequence of bkeep_mprotect() ... PalVirtualMemoryProtect() atomic so that tracked memory protection flags have also been applied to the memory. Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
This test case will occasionally show the following error: > while :; do gramine-direct fork_and_mmap; done ... [P2:T3:fork_and_mmap] error: Sending IPC process-exit notification \ failed: Connection reset by peer (ECONNRESET) Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
When mmap() is run concurrently to a fork() & checkpoint, mmap may add not-yet-mapped memory areas to the memory mapped areas of a process. If the checkpoint code wants to transfer them to the destination then this leads to memory access errors. Therefore, make the addition of the memory area and the actual memory mapping atomic relative to the checkpointing. In particular, make code sequences like the following one atomic relative to checkpointing: bkeep_mmap_xyz() ... PalVirtualMemoryAlloc() Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
stefanberger
force-pushed
the
stefanberger/checkpoint_lock.v2
branch
from
d121287 to
1acd0fb
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.
Description of the changes
3 Test cases are provided that close file descriptors and munmap and change protectiong flags of mmap'ed memory areas during a concurrently running fork's checkpointing stage. To protect file descriptors and mmap'ed memory during the checkpointing a read-writer lock is introduced of which the writer lock is grabbed during the checkpointing and the reader lock is grabbed during close() and munmap() and mprotect() operations. This prevents freeing of file descriptors and unmapping and changing of protection flags of mmap'ed memory areas during the checkpointing. All test cases fail for as long as the fix patches are not applied to libos.
Fixes: #1156
How to test this PR?
This change is