RFR 8224676: Java crash if VSYSCALL is missing

[Vladimir Kempik]

Hello
you are right.
we were using libmusl before sched_getcpu were added.
So it’s not an issue here.

Thanks, Vladimir

> 24 мая 2019 г., в 13:27, Florian Weimer <fweimer at redhat.com> написал(а):
> 
> * 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