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

[Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>]

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)
>>>>>
>>>>
>>>>
>>
>>
>