On 03/30/2016 11:37 PM, Hauke Mehrtens wrote: > 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 I just tried vdso without this patch on a Broadcom BMIPS3300 V0.7 CPU in the BCM4712 SoC and haven't seen any problems without this patch. With the same number of patches applied to the kernel I have problems on the 34Kc CPU. Hauke > >> >> 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) >>>> >>> >>> > >
