Le 26/03/2021 à 11:46, Michael Ellerman a écrit :
Laurent Dufour <lduf...@linux.ibm.com> writes:
Le 25/03/2021 à 17:56, Laurent Dufour a écrit :
Le 25/03/2021 à 17:46, Christophe Leroy a écrit :
Le 25/03/2021 à 17:11, Laurent Dufour a écrit :
Since v5.11 and the changes you made to the VDSO code, it no more exposing
the ELF header at the beginning of the VDSO mapping in user space.
This is confusing CRIU which is checking for this ELF header cookie
(https://github.com/checkpoint-restore/criu/issues/1417).
How does it do on other architectures ?
Good question, I'll double check the CRIU code.
On x86, there are 2 VDSO entries:
7ffff7fcb000-7ffff7fce000 r--p 00000000 00:00 0 [vvar]
7ffff7fce000-7ffff7fcf000 r-xp 00000000 00:00 0 [vdso]
And the VDSO is starting with the ELF header.
I'm not an expert in loading and ELF part and reading the change you made, I
can't identify how this could work now as I'm expecting the loader to need
that ELF header to do the relocation.
I think the loader is able to find it at the expected place.
Actually, it seems the loader relies on the AUX vector AT_SYSINFO_EHDR. I guess
CRIU should do the same.
From my investigation it seems that the first bytes of the VDSO area are now
the vdso_arch_data.
Is the ELF header put somewhere else?
How could the loader process the VDSO without that ELF header?
Like most other architectures, we now have the data section as first page and
the text section follows. So you will likely find the elf header on the second
page.
I'm wondering if the data section you're refering to is the vvar section I can
see on x86.
Many of the other architectures have separate vm_special_mapping's for
the data page and the vdso binary, where the former is called "vvar".
eg, s390:
static struct vm_special_mapping vvar_mapping = {
.name = "[vvar]",
.fault = vvar_fault,
};
static struct vm_special_mapping vdso_mapping = {
.name = "[vdso]",
.mremap = vdso_mremap,
};
I guess we probably should be doing that too.
Dmitry proposed the same, see
https://github.com/0x7f454c46/linux/commit/783c7a2532d2219edbcf555cc540eab05f698d2a
Discussion at https://github.com/checkpoint-restore/criu/issues/1417
Christophe
