RFR 8224676: Java crash if VSYSCALL is missing
Florian Weimer
fweimer at redhat.com
Fri May 24 10:27:21 UTC 2019
* Vladimir Kempik:
> Hello
>
> sched_getcpu may be not present in libc ( in case of musl).
Are you sure? It seems to have been added in 2016.
> if it’s so, then java tries to use VSYSCALL routine which causes sigsegv on some kernel configurations.
>
> there’s a machanism in zgc to cache os::processor_id results and since libc’s sched_getcpu call seems to use getcpu syscall anyway.
> other solutions would be to unify x86_64 and i386 routines in sched::getcpu_syscall.
>
> which would look this:
>
> int os::Linux::sched_getcpu_syscall(void) {
> unsigned int cpu = 0;
> int retval = -1;
>
> #ifndef SYS_getcpu
> #define SYS_getcpu 318
> #endif
318 can refer to various other system calls, depending on the
architecture.
> retval = syscall(SYS_getcpu, &cpu, NULL, NULL);
> return (retval == -1) ? retval : cpu;
> }
glibc uses the vDSO vsyscall, so there's no context switch to the kernel
involved. The LSL in the current vDSO implementation is not very fast,
but it's still not as bad as the context switch.
A future implementation will likely use the rseq area, at which point
the function call overhead will likely dominate.
Anyway, if you want to bypass libc, you should call the vDSO vsyscall,
like this:
#include <dlfcn.h>
#include <stdio.h>
#include <err.h>
int
main (void)
{
void *handle = dlopen ("linux-vdso.so.1", RTLD_NOW | RTLD_NOLOAD);
if (handle == NULL)
errx (1, "dlopen: %s", dlerror ());
void *ptr = dlvsym (handle, "__vdso_getcpu", "LINUX_2.6");
printf ("pointer: %p\n", ptr);
unsigned int cpu = -1;
unsigned int node = -1;
int ret = ((int (*) (unsigned int *, unsigned int *, void *)) ptr)
(&cpu, &node, NULL);
printf ("ret=%d cpu=%u node=%u\n", ret, cpu, node);
return 0;
}
This is part of the userspace ABI, so in theory it should remain stable,
but we thought that of the vsyscall interface as well. (Its removal
should really be a policy flag which can be tweaked on a per-namespace
basis.)
Thanks,
Florian
More information about the hotspot-runtime-dev
mailing list