From: James Hogan <james.hogan@imgtec.com>
To: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH 7/9] MIPS: uprobes: Flush icache via kernel address
Date: Fri, 23 Sep 2016 08:10:42 +0100 [thread overview]
Message-ID: <ECCA6C77-B94C-44DC-B397-B6016607F8B8@imgtec.com> (raw)
In-Reply-To: <57E45ADD.6000202@imgtec.com>
On 22 September 2016 23:27:41 BST, Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> wrote:
>On 09/22/2016 03:13 PM, James Hogan wrote:
>> well it'll do a protected dcache flush (i.e. using CACHEE with EVA).
>Would kmap/kunmap or variants (fixed to work with aliasing dcache) be
>able to take care of colouring / further flushing?
>
>We should flush kernel D-cache and user I-cache in any cache aliasing
>system. I was wrong - a fixed HIGHMEM doesn't do any difference
>actually, because page may be located in directly addressed memory (all
>
>HIGHMEM stuff is irrelevant in this case, kmap returns a lowmem
>address).
Maybe there'd need to be other flush calls too that do the right thing for aliasing.
>
>>
>> In any case, simply changing to the user_ one is a no-op compared to
>leaving as is where patch 9 would probably break it on EVA by making it
>operate only on kernel addresses.
>
>EVA or not has no difference here - kernel address can still be a
>different color to user address.
i'm ignoring aliasing here. If the code doesn't already handle it then this patchset doesn't care. The goal is not to fix aliasing but to prevent any new breakage due to change in semantics in patch 9 to accommodate eva.
EVA does make a difference if left as is, as flush_icache_range will operate on kernel addresses only after patch 9, so the cache op could literally not happen on the right address (irrespective of aliasing, and not a problem without eva).
it also means the ops won't be protected, so failed page fault would i guess cause kernel oops instead of being ignored (maybe impossible to hit in this case, and definitely the exceptional rather than common case)
>
>And keeping kernel I-cache flush does break it really, not EVA.
Right, but mainly because on eva user/kernel icache flushes will start to actually differ in what they do after patch 9 .
--
James Hogan
next prev parent reply other threads:[~2016-09-23 7:10 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-01 16:30 [PATCH 0/9] MIPS: General EVA fixes & cleanups James Hogan
2016-09-01 16:30 ` [PATCH 1/9] MIPS: traps: 64bit kernels should read CP0_EBase 64bit James Hogan
2016-09-01 16:30 ` James Hogan
2016-09-21 13:08 ` Ralf Baechle
2016-09-21 15:01 ` Matt Redfearn
2016-09-21 15:01 ` Matt Redfearn
2016-10-02 10:30 ` Maciej W. Rozycki
2016-10-05 15:56 ` James Hogan
2016-10-05 15:56 ` James Hogan
2016-10-06 16:18 ` Maciej W. Rozycki
2016-10-06 18:05 ` James Hogan
2016-10-06 18:05 ` James Hogan
2016-10-06 19:56 ` Maciej W. Rozycki
2016-10-06 20:19 ` James Hogan
2016-10-06 20:19 ` James Hogan
2016-10-06 22:41 ` Maciej W. Rozycki
2016-10-06 22:50 ` James Hogan
2016-10-06 22:50 ` James Hogan
2016-10-06 23:07 ` Maciej W. Rozycki
2016-10-07 15:35 ` David Daney
2016-10-07 15:41 ` David Daney
2016-10-07 17:39 ` Maciej W. Rozycki
2016-09-01 16:30 ` [PATCH 2/9] MIPS: traps: Convert ebase to KSeg0 James Hogan
2016-09-01 16:30 ` James Hogan
2016-09-01 16:30 ` [PATCH 3/9] MIPS: traps: Ensure full EBase is written James Hogan
2016-09-01 16:30 ` James Hogan
2016-09-21 13:19 ` Ralf Baechle
2016-09-01 16:30 ` [PATCH 4/9] MIPS: c-r4k: Drop bc_wback_inv() from icache flush James Hogan
2016-09-01 16:30 ` James Hogan
2016-09-01 16:30 ` [PATCH 5/9] MIPS: c-r4k: Split user/kernel flush_icache_range() James Hogan
2016-09-01 16:30 ` James Hogan
2016-09-01 16:30 ` [PATCH 6/9] MIPS: cacheflush: Use __flush_icache_user_range() James Hogan
2016-09-01 16:30 ` James Hogan
2016-09-01 16:30 ` [PATCH 7/9] MIPS: uprobes: Flush icache via kernel address James Hogan
2016-09-01 16:30 ` James Hogan
2016-09-21 13:26 ` Ralf Baechle
2016-09-21 18:15 ` Leonid Yegoshin
2016-09-21 18:15 ` Leonid Yegoshin
2016-09-22 21:15 ` James Hogan
2016-09-22 21:15 ` James Hogan
2016-09-22 21:38 ` Leonid Yegoshin
2016-09-22 21:38 ` Leonid Yegoshin
2016-09-22 21:42 ` Leonid Yegoshin
2016-09-22 21:42 ` Leonid Yegoshin
2016-09-22 22:13 ` James Hogan
2016-09-22 22:27 ` Leonid Yegoshin
2016-09-22 22:27 ` Leonid Yegoshin
2016-09-23 7:10 ` James Hogan [this message]
2016-09-01 16:30 ` [PATCH 8/9] MIPS: KVM: Use __local_flush_icache_user_range() James Hogan
2016-09-01 16:30 ` [PATCH 9/9] MIPS: c-r4k: Fix flush_icache_range() for EVA James Hogan
2016-09-01 16:30 ` James Hogan
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=ECCA6C77-B94C-44DC-B397-B6016607F8B8@imgtec.com \
--to=james.hogan@imgtec.com \
--cc=Leonid.Yegoshin@imgtec.com \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.