arm: a0d2fcd62ac2 ("vdso/ARM: Make union vdso_data_store available for all architectures")
arm64: d0fba04847ae ("arm64: vdso: Use generic union vdso_data_store")
mips: d697a9997a0d ("MIPS: vdso: Use generic union vdso_data_store")
s390: cb3444cfdb48 ("s390/vdso: Use generic union vdso_data_store")
riscv: eba755314fa7 ("riscv: vdso: Use generic union vdso_data_store")
ia64 is dead
nds32 is dead
hexagon has a bunch of vdso work in the logs as well.
There is also a6c19dfe3994 ("arm64,ia64,ppc,s390,sh,tile,um,x86,mm: remove default gate area")
I do not see sparc changing away from what the patches were doing, but
again, the arch_unmap() seems to do nothing there as well.
So, what I was looking to do is to avoid a call to arch specific
functions that does nothing but set the vdso pointer to NULL for
powerpc.
The thread referenced in the git bug [1] seems to indicate this is for
CRIU unmapping/restoring a task, but CRIU now just moves the vdso
mapping (or just works on ppc at this point?). Since [2] hasn't landed,
isn't this still broken for CRIU on powerpc as it is?
So, are we keeping the unmap_arch() function around, which has errors
that were never fixed, for a single application that utilizes a newer
method of moving the vdso anyways?
On the note of CRIU, it seems it cannot handle tasks which don't have
the vdso mapped anymore [3], so setting it to NULL is probably a bad
plan even for that one application?
So, I think this just leaves the fallback when the VDSO is unmapped..
Well, it seems what people have been doing is unmap the vdso to stop
these functions from working [4]. At least this is what some users are
doing. The ability to replace this vma with a guard vma leads me to
believe that other archs don't fall back at all - please correct me if
I'm wrong!
I also cannot find any reference to other archs clearing the
context.vdso (aside from failures in __setup_additional_pages).
But maybe I don't fully understand how this works?
Thanks,
Liam
[1] https://lore.kernel.org/lkml/87d0lht1c0.fsf@xxxxxxxxxxxxxxxxxxxxxxxx/
[2] https://lore.kernel.org/lkml/9c2b2826-4083-fc9c-5a4d-c101858dd560@xxxxxxxxxxxxxxxxxx/
[3] https://github.com/checkpoint-restore/criu/issues/488
[4] https://github.com/insanitybit/void-ship
Thanks,
Liam
