[PATCH v2] MIPS: vdso: flush the vdso data page to update it on all processes

[PATCH v2] MIPS: vdso: flush the vdso data page to update it on all processes

[Hauke Mehrtens]

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@hauke-m.de>
Cc: <stable@vger.kernel.org> # v4.4+
---
 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)
-- 
2.7.0

Re: [PATCH v2] MIPS: vdso: flush the vdso data page to update it on all processes

[Hauke Mehrtens]

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@hauke-m.de>
> Cc: <stable@vger.kernel.org> # 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)
> 

Re: [PATCH v2] MIPS: vdso: flush the vdso data page to update it on all processes

[Zubair Lutfullah Kakakhel]

Hi Hauke,

Could you share details of what version of glibc/rfs setup you are using?

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@hauke-m.de>
>> Cc: <stable@vger.kernel.org> # 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)
>>
>
>

Re: [PATCH v2] MIPS: vdso: flush the vdso data page to update it on all processes

[Hauke Mehrtens]

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@hauke-m.de>
>>> Cc: <stable@vger.kernel.org> # 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)
>>>
>>
>>

Re: [PATCH v2] MIPS: vdso: flush the vdso data page to update it on all processes

[Hauke Mehrtens]

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@hauke-m.de>
>>>> Cc: <stable@vger.kernel.org> # 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)
>>>>
>>>
>>>
> 
> 

Re: [PATCH v2] MIPS: vdso: flush the vdso data page to update it on all processes

[Zubair Lutfullah Kakakhel]

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 <hauke@hauke-m.de>
>>>>> Cc: <stable@vger.kernel.org> # 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)
>>>>>
>>>>
>>>>
>>
>>
>

Re: [PATCH v2] MIPS: vdso: flush the vdso data page to update it on all processes

[Ralf Baechle]

On Tue, Mar 29, 2016 at 11:36:53PM +0200, 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@hauke-m.de>
> > Cc: <stable@vger.kernel.org> # 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.

This is because there may be a stale cache entry on the user virtual
address.  In order to correctly flush the cache one either has to do
one of the following.

 - use indexed cache ops to flush all matching cache ways
 - flush the user space address while running in the mm context of the
   affected process.  Since this would need to be done for all processes
   this is not a very practical approach.
 - pick a suitable VA for example in KSEG0 or XKPHYS and user that for
   the flush operation.

Indexed cacheops are not globalized by the MIPS CM so I'd go for the
last operation.

  Ralf