Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto deduplication on restore does not work in this fork #3

Open
rvansa opened this issue Apr 3, 2023 · 3 comments
Open

Auto deduplication on restore does not work in this fork #3

rvansa opened this issue Apr 3, 2023 · 3 comments

Comments

@rvansa
Copy link
Member

rvansa commented Apr 3, 2023

Trying out the criu restore --auto-dedup feature fails with this fork:

When using on the first restore (doesn't make much sense):

$ sleep 3600 & export PID=$!
[1] 676638
rvansa@rvansa:/tmp$ criu dump -D /tmp/s1 -t $PID --shell-job
Warn  (compel/arch/x86/src/lib/infect.c:352): Will restore 676638 with interrupted system call
[1]+  Killed                  sleep 3600
rvansa@rvansa:/tmp$ criu restore -D /tmp/s1 -d --shell-job --auto-dedup
pie: 676638: Error (criu/pie/util-vdso.c:92): vdso: ELF header magic mismatch
pie: 676638: Error (criu/pie/restorer.c:2056): Restorer fail 676638
Error (criu/cr-restore.c:2593): Restoring FAILED.
Error (criu/cr-restore.c:1536): 676638 exited, status=1

but actually if I do one a normal restore and second dump, the next restore fails with the same error.

I managed to dump/restore twice when using --auto-dedup with dump.

@rvansa
Copy link
Member Author

rvansa commented Apr 3, 2023

I can run restore with --auto-dedup using the 'official' version 3.17.1

@rvansa
Copy link
Member Author

rvansa commented Apr 4, 2023

For the record, I can dump with -crac version and restore with 3.17.1. Logs with -v4 don't show anything unexpectedly different until loading VDSO:

< pie: 686159: vdso: Parsing at 0x7fff907b8000 0x7fff907ba000
< pie: 686159: vdso: PT_LOAD p_vaddr: 0x0
< pie: 686159: vdso: DT_HASH: 0x120
< pie: 686159: vdso: DT_STRTAB: 0x300
< pie: 686159: vdso: DT_SYMTAB: 0x1c8
< pie: 686159: vdso: DT_STRSZ: 0x8b
< pie: 686159: vdso: DT_SYMENT: 0x18
< pie: 686159: vdso: nbucket 0x3 nchain 0xd bucket 0x7fff907b8128 chain 0x7fff907b8134
< pie: 686159: vdso: image [vdso] 0x7fff907b8000-0x7fff907ba000 [vvar] 0x7fff907b4000-0x7fff907b8000
< pie: 686159: vdso: Runtime vdso/vvar matches dumpee, remap inplace
< pie: 686159: vdso: Remap rt-vdso 0x2e000 -> 0x7fff907b8000
< pie: 686159: vdso: Remap rt-vvar 0x2a000 -> 0x7fff907b4000
< pie: 686159: vdso: Using gettimeofday() on vdso at 0x7fff907b8c50
< pie: 686159: Restoring scheduler params 0.0.0
< pie: 686159: rseq: rseq_abi_pointer = 0x7f713b5f00e0 signature = 0x53053053
< pie: 686159: 686159: Restored
.... vs. ....
> pie: 685311: vdso: Parsing at 0x7ffeaf8e7000 0x7ffeaf8e9000
> pie: 685311: Error (criu/pie/util-vdso.c:92): vdso: ELF header magic mismatch
> pie: 685311: Error (criu/pie/restorer.c:2056): Restorer fail 685311
> Error (criu/cr-restore.c:2593): Restoring FAILED.
> Error (criu/cr-restore.c:1536): 685311 exited, status=1

@rvansa
Copy link
Member Author

rvansa commented Apr 4, 2023

I found that the difference is due to mmaping files by default in -crac; with explicit --no-mmap-page-image the --auto-dedup works. So we should check for these flags and make them incompatible - it does not make sense to punch hole into file when it's mmap, unless we break the association.

pushkarnk referenced this issue in canonical/crac-criu Jul 13, 2024
read_ns_sys_file() can return an error, but we are trying to parse a
buffer before checking a return code.

CID 417395 (#3 of 3): String not null terminated (STRING_NULL)
2. string_null: Passing unterminated string buf to strtol, which expects
   a null-terminated string.

Signed-off-by: Andrei Vagin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant