uffd: Disable image deduplication after fork

[liusdu]

After a fork, both the child and parent processes may trigger a page fault (#PF) at the same virtual address, referencing the same position in the page image. If deduplication is enabled, the last process to trigger the page fault will fail.

Therefore, deduplication should be disabled after a fork to prevent this issue.

[rst0git]

If deduplication is enabled, the last process to trigger the page fault will fail.

Would it be possible to add a ZDTM test for this use-case?

[liusdu]

If deduplication is enabled, the last process to trigger the page fault will fail.

Would it be possible to add a ZDTM test for this use-case?

I will add a ZDTM testcase later. The follow test case can reproduce this issue.

• source code

#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#include <string.h>
#include <signal.h>
#include <sched.h>


#define VALUE 0x1001
#define STACK_SIZE (1024 * 1024)

int validate_memory(void *arg)
{
    if  (*(int *)arg != VALUE) {
        printf("memory is corrupted\n");
        return -1;
    }
    printf("memory: %x\n", *(int *)arg);
    return 0;
}

int main() {
    int pid = 0;
    char *stack;
    int *buffer;;
     int flags = CLONE_VFORK;
    stack = malloc(STACK_SIZE + 4096);
    if (stack == NULL) {
        perror("malloc");
        exit(EXIT_FAILURE);
    }
    buffer = (int *)(stack + STACK_SIZE);
    buffer[0] = VALUE;

    kill(getpid(), 19);
    if (clone(validate_memory, buffer, flags, (void *)buffer) == -1) {
        perror("clone");
        free(stack);
        exit(EXIT_FAILURE);
    }
    validate_memory(buffer);

    return 0;
}

• steps

  gcc -o clone clone.c 
  setsid ./clone
  criu dump --shell-job  -vvvv --tree `pidof ./clone` -o dumo.log  --images-dir ./ckp 
  criu lazy-pages -vvvv -o lp.log  --auto-dedup --images-dir ckp/ &
  criu  restore -vvvv -o restore.log  --images-dir  ./ckp/ --lazy-pages -j --no-background-fetch  &
  kill -s SIGCONT `ps aux | grep '\[clone\]' | awk '{print $2}'`
 

[rst0git]

@liusdu What is the use-case for this option?

cc: @rppt

[liusdu]

This is for the test case. We know that CRIU can set up pages in the background or on demand in lazy-page mode. We must disable the background mode to ensure that both the child and parent processes trigger two page faults (#PF). Otherwise, by the time the child and parent processes start running, the lazy page server may have already completed its tasks and exited

[rst0git]

Ah, I see. We typically add command-line options to enable new CRIU features and document these options in the man page and criu --help. However, having a large number of options may lead to confusion for users who are not familiar with the available CRIU features.

Would it be possible to use an environment variable instead? For example, something like the following:

CRIU_DISABLE_BACKGROUND_LAZY_PAGE_FETCH=1  criu restore ...

[liusdu]

ok~

[rppt]

Ah, I see. We typically add command-line options to enable new CRIU features and document these options in the man page and criu --help. However, having a large number of options may lead to confusion for users who are not familiar with the available CRIU features.

Would it be possible to use an environment variable instead? For example, something like the following:

CRIU_DISABLE_BACKGROUND_LAZY_PAGE_FETCH=1  criu restore ...

Or maybe even fault injection mechanism, because normally we don't want to disable the background fetch

[duguhaotian]

can you show some error message of this issuse?

[rppt]

I'm not sure I understand how this would prevent background fetch

[rppt]

Ah, I see. We typically add command-line options to enable new CRIU features and document these options in the man page and criu --help. However, having a large number of options may lead to confusion for users who are not familiar with the available CRIU features.

Would it be possible to use an environment variable instead? For example, something like the following:

CRIU_DISABLE_BACKGROUND_LAZY_PAGE_FETCH=1  criu restore ...

Or maybe even fault injection mechanism, because normally we don't want to disable the background fetch