All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: James Hogan <james.hogan@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: Thu, 22 Sep 2016 14:38:33 -0700	[thread overview]
Message-ID: <57E44F59.5050600@imgtec.com> (raw)
In-Reply-To: <20160922211527.GB7352@jhogan-linux.le.imgtec.org>

On 09/22/2016 02:15 PM, James Hogan wrote:
> On Wed, Sep 21, 2016 at 11:15:55AM -0700, Leonid Yegoshin wrote:
>> On 09/21/2016 06:26 AM, Ralf Baechle wrote:
>>> On Thu, Sep 01, 2016 at 05:30:13PM +0100, James Hogan wrote:
>>>
>>>> Update arch_uprobe_copy_ixol() to use the kmap_atomic() based kernel
>>>> address to flush the icache with flush_icache_range(), rather than the
>>>> user mapping. We have the kernel mapping available anyway and this
>>>> avoids having to switch to using the new __flush_icache_user_range() for
>>>> the sake of Enhanced Virtual Addressing (EVA) where flush_icache_range()
>>>> will become ineffective on user addresses.
>>>>
>>>> Signed-off-by: James Hogan <james.hogan@imgtec.com>
>>>> Cc: Ralf Baechle <ralf@linux-mips.org>
>>>> Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
>>>> Cc: linux-mips@linux-mips.org
>>>> ---
>>>>    arch/mips/kernel/uprobes.c | 13 ++++---------
>>>>    1 file changed, 4 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/arch/mips/kernel/uprobes.c b/arch/mips/kernel/uprobes.c
>>>> index 8452d933a645..9a507ab1ea38 100644
>>>> --- a/arch/mips/kernel/uprobes.c
>>>> +++ b/arch/mips/kernel/uprobes.c
>>>> @@ -301,19 +301,14 @@ int set_orig_insn(struct arch_uprobe *auprobe, struct mm_struct *mm,
>>>>    void __weak arch_uprobe_copy_ixol(struct page *page, unsigned long vaddr,
>>>>    				  void *src, unsigned long len)
>>>>    {
>>>> -	void *kaddr;
>>>> +	void *kaddr, kstart;
>>>>    
>>>>    	/* Initialize the slot */
>>>>    	kaddr = kmap_atomic(page);
>>>> -	memcpy(kaddr + (vaddr & ~PAGE_MASK), src, len);
>>>> +	kstart = kaddr + (vaddr & ~PAGE_MASK);
>>>> +	memcpy(kstart, src, len);
>>>> +	flush_icache_range(kstart, kstart + len);
>>>>    	kunmap_atomic(kaddr);
>>>> -
>>>> -	/*
>>>> -	 * The MIPS version of flush_icache_range will operate safely on
>>>> -	 * user space addresses and more importantly, it doesn't require a
>>>> -	 * VMA argument.
>>>> -	 */
>>>> -	flush_icache_range(vaddr, vaddr + len);
>>> I can't convince myself this is right wrt. to cache aliases ...
>>>
>>>     Ralf
>>>
>> It is incorrect if there is I-cache aliasing (very rare) and there is no
>> HIGHMEM cache aliasing fix (not fixed). But top tree Linux doesn't work
>> with I-cache aliasing either.
> Well its pretty trivial to just use the newly introduced
> __flush_icache_user_range() on the user address instead of using
> flush_icache_range().

It may not work - you should flush kernel Dcache but user Icache and 
__flush_icache_user_range() doesn't do it. Some CPU may accept an 
aliasing CACHE instruction and flush both colors and it can work in this 
case.

Besides that, I had no time to research - does uprobe keep data on the 
same page as code? If yes, then we may want to make a special flush 
sequence for cache aliasing systems here. (User-Dcache, Write-to-page, 
Kernel-Dcache, User-Icache).

- Leonid

WARNING: multiple messages have this Message-ID (diff)
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: James Hogan <james.hogan@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: Thu, 22 Sep 2016 14:38:33 -0700	[thread overview]
Message-ID: <57E44F59.5050600@imgtec.com> (raw)
Message-ID: <20160922213833.DOoFAiqeBGXBl_0n0LW_DYWiYOAsfRW2ZEIssIE4e3s@z> (raw)
In-Reply-To: <20160922211527.GB7352@jhogan-linux.le.imgtec.org>

On 09/22/2016 02:15 PM, James Hogan wrote:
> On Wed, Sep 21, 2016 at 11:15:55AM -0700, Leonid Yegoshin wrote:
>> On 09/21/2016 06:26 AM, Ralf Baechle wrote:
>>> On Thu, Sep 01, 2016 at 05:30:13PM +0100, James Hogan wrote:
>>>
>>>> Update arch_uprobe_copy_ixol() to use the kmap_atomic() based kernel
>>>> address to flush the icache with flush_icache_range(), rather than the
>>>> user mapping. We have the kernel mapping available anyway and this
>>>> avoids having to switch to using the new __flush_icache_user_range() for
>>>> the sake of Enhanced Virtual Addressing (EVA) where flush_icache_range()
>>>> will become ineffective on user addresses.
>>>>
>>>> Signed-off-by: James Hogan <james.hogan@imgtec.com>
>>>> Cc: Ralf Baechle <ralf@linux-mips.org>
>>>> Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
>>>> Cc: linux-mips@linux-mips.org
>>>> ---
>>>>    arch/mips/kernel/uprobes.c | 13 ++++---------
>>>>    1 file changed, 4 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/arch/mips/kernel/uprobes.c b/arch/mips/kernel/uprobes.c
>>>> index 8452d933a645..9a507ab1ea38 100644
>>>> --- a/arch/mips/kernel/uprobes.c
>>>> +++ b/arch/mips/kernel/uprobes.c
>>>> @@ -301,19 +301,14 @@ int set_orig_insn(struct arch_uprobe *auprobe, struct mm_struct *mm,
>>>>    void __weak arch_uprobe_copy_ixol(struct page *page, unsigned long vaddr,
>>>>    				  void *src, unsigned long len)
>>>>    {
>>>> -	void *kaddr;
>>>> +	void *kaddr, kstart;
>>>>    
>>>>    	/* Initialize the slot */
>>>>    	kaddr = kmap_atomic(page);
>>>> -	memcpy(kaddr + (vaddr & ~PAGE_MASK), src, len);
>>>> +	kstart = kaddr + (vaddr & ~PAGE_MASK);
>>>> +	memcpy(kstart, src, len);
>>>> +	flush_icache_range(kstart, kstart + len);
>>>>    	kunmap_atomic(kaddr);
>>>> -
>>>> -	/*
>>>> -	 * The MIPS version of flush_icache_range will operate safely on
>>>> -	 * user space addresses and more importantly, it doesn't require a
>>>> -	 * VMA argument.
>>>> -	 */
>>>> -	flush_icache_range(vaddr, vaddr + len);
>>> I can't convince myself this is right wrt. to cache aliases ...
>>>
>>>     Ralf
>>>
>> It is incorrect if there is I-cache aliasing (very rare) and there is no
>> HIGHMEM cache aliasing fix (not fixed). But top tree Linux doesn't work
>> with I-cache aliasing either.
> Well its pretty trivial to just use the newly introduced
> __flush_icache_user_range() on the user address instead of using
> flush_icache_range().

It may not work - you should flush kernel Dcache but user Icache and 
__flush_icache_user_range() doesn't do it. Some CPU may accept an 
aliasing CACHE instruction and flush both colors and it can work in this 
case.

Besides that, I had no time to research - does uprobe keep data on the 
same page as code? If yes, then we may want to make a special flush 
sequence for cache aliasing systems here. (User-Dcache, Write-to-page, 
Kernel-Dcache, User-Icache).

- Leonid

  reply	other threads:[~2016-09-22 21:38 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 [this message]
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
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=57E44F59.5050600@imgtec.com \
    --to=leonid.yegoshin@imgtec.com \
    --cc=james.hogan@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.