[PATCH 6/9] uprobes: flush cache after xol write
Oleg Nesterov
oleg at redhat.com
Sat Nov 3 12:33:01 EDT 2012
On 10/29, Ananth N Mavinakayanahalli wrote:
>
> On Fri, Oct 26, 2012 at 06:39:51PM +0200, Oleg Nesterov wrote:
> > >
> > > > OTOH, I do not understand this stuff, everything is nop on x86. And
> > > > when I look into Documentation/cachetlb.txt I am starting to think
> > > > that may be this needs flush_icache_user_range instead?
> > > >
> > > > Rabin, Ananth could you clarify this?
> > >
> > > Yes. We need flush_icache_user_range(). Though for x86 its always been a
> > > nop, one never knows if there is some Power4 or older machine out there
> > > that is still being used. We are fine for Power5 and later.
> >
> > This is bad...
> >
> > flush_icache_user needs vma. perhaps just to check VM_EXEC...
> >
> > So let me repeat to be sure I really understand, do you confirm that
> > _in general_ flush_dcache_page() is not enough?
>
> flush_dcache_page() on powerpc already checks for
> CPU_FTR_COHERENT_ICACHE. So, yes, that is enough.
Thanks Ananth.
Still it is not clear to me if flush_dcache_page() would be always right
if we add the new port.
OK. So I assume we need the fix and I am going to apply the patch below.
Ananth, Rabin, will you ack it (including the comment I affed) ?
Oleg.
------------------------------------------------------------------------------
[PATCH] uprobes: flush cache after xol write
From: Rabin Vincent <rabin at rab.in>
Flush the cache so that the instructions written to the XOL area are
visible.
Signed-off-by: Rabin Vincent <rabin at rab.in>
--- x/kernel/events/uprobes.c
+++ x/kernel/events/uprobes.c
@@ -1199,6 +1199,11 @@ static unsigned long xol_get_insn_slot(s
vaddr = kmap_atomic(area->page);
memcpy(vaddr + offset, uprobe->arch.insn, MAX_UINSN_BYTES);
kunmap_atomic(vaddr);
+ /*
+ * We probably need flush_icache_user_range() but it needs vma.
+ * This should work on supported architectures too.
+ */
+ flush_dcache_page(area->page);
return current->utask->xol_vaddr;
}
More information about the linux-arm-kernel
mailing list