On 03/30/2016 05:21 PM, Zubair Lutfullah Kakakhel wrote: > Hi Hauke, > > Could you share details of what version of glibc/rfs setup you are using? Hi, I am using the musl libc version 1.1.4 in OpenWrt. musl uses the same vdso code on arm and x86, it just needed some extensions to support the -ENOSYS return value which is not returned by the other architectures. I removed the following patches from OpenWrt to activate vdso gettimeofday in kernel 4.4 again: target/linux/generic/patches-4.4/206-mips-disable-vdso.patch target/linux/generic/patches-4.4/340-MIPS-deactivate-gettimeofday-vdso.patch > > Thanks. > > Regards, > ZubairLK > > On 29/03/16 22:36, Hauke Mehrtens wrote: >> On 02/21/2016 06:08 PM, Hauke Mehrtens wrote: >>> Without flushing the vdso data page the vdso call is working on dated >>> or unsynced data. This resulted in problems where the clock_gettime >>> vdso call returned a time 6 seconds later after a 3 seconds sleep, >>> while the syscall reported a time 3 sounds later, like expected. This >>> happened very often and I got these ping results for example: >>> >>> root@OpenWrt:/# ping 192.168.1.255 >>> PING 192.168.1.255 (192.168.1.255): 56 data bytes >>> 64 bytes from 192.168.1.3: seq=0 ttl=64 time=0.688 ms >>> 64 bytes from 192.168.1.3: seq=1 ttl=64 time=4294172.045 ms >>> 64 bytes from 192.168.1.3: seq=2 ttl=64 time=4293968.105 ms >>> 64 bytes from 192.168.1.3: seq=3 ttl=64 time=4294055.920 ms >>> 64 bytes from 192.168.1.3: seq=4 ttl=64 time=4294671.913 ms >>> >>> This was tested on a Lantiq/Intel VRX288 (MIPS BE 34Kc V5.6 CPU with >>> two VPEs) >>> >>> Signed-off-by: Hauke Mehrtens <hauke@xxxxxxxxxx> >>> Cc: <stable@xxxxxxxxxxxxxxx> # v4.4+ >> >> This patch flushes the complete dcache of the CPU if cpu_has_dc_aliases >> is set. >> >> Calling flush_dcache_page(virt_to_page(&vdso_data)); improved the >> situation a litte bit but did not fix my problem. >> >> Could someone from Imagination please look into this problem. The page >> is linked into many virtual address spaces and when it gets modified by >> the kernel the user space processes are still accessing partly old data, >> even when lush_dcache_page() was called. >> >>> --- >>> arch/mips/kernel/vdso.c | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/arch/mips/kernel/vdso.c b/arch/mips/kernel/vdso.c >>> index 975e997..8b0d974 100644 >>> --- a/arch/mips/kernel/vdso.c >>> +++ b/arch/mips/kernel/vdso.c >>> @@ -20,6 +20,8 @@ >>> #include <linux/timekeeper_internal.h> >>> >>> #include <asm/abi.h> >>> +#include <asm/cacheflush.h> >>> +#include <asm/page.h> >>> #include <asm/vdso.h> >>> >>> /* Kernel-provided data used by the VDSO. */ >>> @@ -85,6 +87,8 @@ void update_vsyscall(struct timekeeper *tk) >>> } >>> >>> vdso_data_write_end(&vdso_data); >>> + flush_cache_vmap((unsigned long)&vdso_data, >>> + (unsigned long)&vdso_data + sizeof(vdso_data)); >>> } >>> >>> void update_vsyscall_tz(void) >>> @@ -93,6 +97,8 @@ void update_vsyscall_tz(void) >>> vdso_data.tz_minuteswest = sys_tz.tz_minuteswest; >>> vdso_data.tz_dsttime = sys_tz.tz_dsttime; >>> } >>> + flush_cache_vmap((unsigned long)&vdso_data, >>> + (unsigned long)&vdso_data + sizeof(vdso_data)); >>> } >>> >>> int arch_setup_additional_pages(struct linux_binprm *bprm, int >>> uses_interp) >>> >> >>
