* Salvatore Bonaccorso:
> [ Changes ]
> Quoting the upsream commit is likely the best to explain the changes:
>
> | cr-restore: rseq: dynamically handle *libc with rseq
> | Before this patch we assumed that CRIU is compiled against
> | the same GLibc as it runs with. But as we see from real
> | world examples like #1935 it's not always true.
> |
> | The idea of this patch is to detect rseq configuration
> | for the main CRIU process and use it to unregister
> | rseq for all further child processes. It's correct,
> | because we restore pstree using clone*() syscalls,
> | don't use exec*() (!) syscalls, so rseq gets inherited
> | in the kernel and rseq configuration remains the same
> | for all children processes.
There's are further commit you should consider picking up:
commit 089345f77a34d1bc7ef146d650636afcd3cdda21
Author: Florian Weimer <fwei...@redhat.com>
Date: Wed Jul 10 18:34:50 2024 +0200
Adjust to glibc __rseq_size semantic change
In commit 2e456ccf0c34a056e3ccafac4a0c7effef14d918 ("Linux: Make
__rseq_size useful for feature detection (bug 31965)") glibc 2.40
changed the meaning of __rseq_size slightly: it is now the size
of the active/feature area (20 bytes initially), and not the size
of the entire initially defined struct (32 bytes including padding).
The reason for the change is that the size including padding does not
allow detection of newly added features while previously unused
padding is consumed.
The prep_libc_rseq_info change in criu/cr-restore.c is not necessary
on kernels which have full ptrace support for obtaining rseq
information because the code is not used. On older kernels, it is
a correctness fix because with size 20 (the new value), rseq
registeration would fail.
The two other changes are required to make rseq unregistration work
in tests.
Signed-off-by: Florian Weimer <fwei...@redhat.com>
