From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailapp01.imgtec.com ([195.59.15.196]:34937 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753293AbcDDKQg (ORCPT ); Mon, 4 Apr 2016 06:16:36 -0400 Subject: Re: [PATCH v2] MIPS: vdso: flush the vdso data page to update it on all processes To: Hauke Mehrtens , , References: <1456074518-13163-1-git-send-email-hauke@hauke-m.de> <56FAF575.4070607@hauke-m.de> <56FBEEFF.10406@imgtec.com> <56FC472B.1040801@hauke-m.de> <56FFA0C4.80601@hauke-m.de> CC: , , "# v4 . 4+" From: Zubair Lutfullah Kakakhel Message-ID: <57023ED7.5070905@imgtec.com> Date: Mon, 4 Apr 2016 11:15:51 +0100 MIME-Version: 1.0 In-Reply-To: <56FFA0C4.80601@hauke-m.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: Hi, On 02/04/16 11:36, Hauke Mehrtens wrote: > 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. Thanks for the update. Out of curiosity, are there any Endian difference between these two platforms? Regards ZubairLK > > 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 >>>>> Cc: # 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 >>>>> >>>>> #include >>>>> +#include >>>>> +#include >>>>> #include >>>>> >>>>> /* 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) >>>>> >>>> >>>> >> >> >