http://bugzilla.suse.com/show_bug.cgi?id=1170495 http://bugzilla.suse.com/show_bug.cgi?id=1170495#c1 --- Comment #1 from Michael Schröder --- Hmm, Fabian just wrote me that it's probably just the clock_gettime64 syscall missing from docker's seccomp profile. So this is most likely not a kernel bug. You may want to investigate what's wrong with the vdso call, though. This is independent of docker, changing the clocksource from tsc to hpet makes the vdso code do a syscall. This is guest kernel-pae-5.6.4-1.2.i686 running in a host kernel-default-4.12.14-lp151.28.48.1.x86_64 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1170495 http://bugzilla.suse.com/show_bug.cgi?id=1170495#c3 Michal Suchanek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msuchanek@suse.com --- Comment #3 from Michal Suchanek --- To be very specific here: Many seccomp profiles only allow specific syscalls. However, to be able to support post Y2038 dates, large files, and whatnot 64bit syscall variant needs to be called on a 32bit system. Profiles that allow a 32bit syscall but not its 64bit variant are broken. With support for post Y2038 dates many 32bit applications start calling clock_gettime64 instead of clock_gettime which exposes this issue. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1170495 http://bugzilla.suse.com/show_bug.cgi?id=1170495#c5 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jmassaguerpla@suse.com, | |schwab@suse.com Assignee|kernel-maintainers@forge.pr |asarai@suse.com |ovo.novell.com | --- Comment #5 from Fabian Vogt --- Reassigning to docker maintainers, as that's the root cause. (In reply to Michael Schröder from comment #4)

Note that glibc implements clock_gettime() with a clock_gettime64() call on 32bit, so this is not just some applications...

Unlike the statx case, here it's actually feasible to work around this in glibc (if desirable) by just treating EPERM like ENOSYS. Adding glibc maintainer to CC.

Anyway, the big question is why the syscall is needed at all and it's not just the vdso code reading the values from memory.

Some clocksources don't have vdso support. I see the same here with kvm-clock, but after switching to tsc vdso works again. So this is presumably expected. -- You are receiving this mail because: You are on the CC list for the bug.