From: Ralf Baechle <ralf@linux-mips.org>
To: Hauke Mehrtens <hauke@hauke-m.de>
Cc: linux-mips@linux-mips.org, alex.smith@imgtec.com,
sergei.shtylyov@cogentembedded.com,
"# v4 . 4+" <stable@vger.kernel.org>
Subject: Re: [PATCH v2] MIPS: vdso: flush the vdso data page to update it on all processes
Date: Mon, 4 Apr 2016 13:03:20 +0200 [thread overview]
Message-ID: <20160404110320.GC15222@linux-mips.org> (raw)
In-Reply-To: <56FAF575.4070607@hauke-m.de>
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
prev parent reply other threads:[~2016-04-04 11:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-21 17:08 [PATCH v2] MIPS: vdso: flush the vdso data page to update it on all processes Hauke Mehrtens
2016-03-29 21:36 ` Hauke Mehrtens
2016-03-30 15:21 ` Zubair Lutfullah Kakakhel
2016-03-30 21:37 ` Hauke Mehrtens
2016-04-02 10:36 ` Hauke Mehrtens
2016-04-04 10:15 ` Zubair Lutfullah Kakakhel
2016-04-04 11:03 ` Ralf Baechle [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160404110320.GC15222@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=alex.smith@imgtec.com \
--cc=hauke@hauke-m.de \
--cc=linux-mips@linux-mips.org \
--cc=sergei.shtylyov@cogentembedded.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox