Skip to content

Commit

Permalink
[LibOS] Lock mmap'ed memory area from mmap during checkpointing
Browse files Browse the repository at this point in the history
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>
  • Loading branch information
stefanberger committed Oct 13, 2023
1 parent 0af4f8f commit 0548ef1
Showing 1 changed file with 7 additions and 0 deletions.
7 changes: 7 additions & 0 deletions libos/src/sys/libos_mmap.c
Original file line number Diff line number Diff line change
Expand Up @@ -67,6 +67,7 @@ void* libos_syscall_mmap(void* addr, size_t length, int prot, int flags, int fd,
unsigned long offset) {
struct libos_handle* hdl = NULL;
long ret = 0;
bool unlock = false;

ret = check_prot(prot);
if (ret < 0)
Expand Down Expand Up @@ -153,6 +154,9 @@ void* libos_syscall_mmap(void* addr, size_t length, int prot, int flags, int fd,
flags &= ~MAP_32BIT;
#endif

rwlock_read_lock(&checkpoint_lock);
unlock = true;

if (flags & (MAP_FIXED | MAP_FIXED_NOREPLACE)) {
/* We know that `addr + length` does not overflow (`access_ok` above). */
if (addr < g_pal_public_state->memory_address_start
Expand Down Expand Up @@ -254,6 +258,9 @@ void* libos_syscall_mmap(void* addr, size_t length, int prot, int flags, int fd,
}

out_handle:
if (unlock)
rwlock_read_unlock(&checkpoint_lock);

if (hdl) {
put_handle(hdl);
}
Expand Down

0 comments on commit 0548ef1

Please sign in to comment.