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@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. 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 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html