[RFC PATCH v3] ARM: uprobes need icache flush after xol write

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Wed, Apr 16, 2014 at 11:47:40AM -0400, David Miller wrote:
> From: Oleg Nesterov <oleg@redhat.com>
> Date: Wed, 16 Apr 2014 17:29:46 +0200
> 
> > On 04/16, David Miller wrote:
> >>
> >> From: Oleg Nesterov <oleg@redhat.com>
> >> Date: Wed, 16 Apr 2014 17:06:46 +0200
> >>
> >> > Off-topic, I am just curious... can't someone explain why flush_pfn_alias()
> >> > or flush_icache_alias() can't race with itself ? I have no idea what they do,
> >> > but what if another thread calls the same function with the same CACHE_COLOUR()
> >> > right after set_pte_ext?
> >>
> >> PTE modifications are supposed to run with the page table lock held.
> > 
> > OK, but __access_remote_vm() doesn't take ptl?
> > 
> > And on arm copy_to_user_page()->flush_ptrace_access()->flush_pfn_alias()
> > does this.
> 
> Well, for one thing, PTE's can't gain permissions except under mmap_sem
> which __access_remote_vm() does hold.
> 
> But I see what you're saying, flush_pfn_alias() is doing something
> different.  It's not making user mappings, but kernel ones in order
> to implement the cache flush.
> 
> On sparc64 we handle this situation by hand-loading the mappings into
> the TLB, doing the operation using the mappings, then flushing it out
> of the TLB, all with interrupts disabled.
> 
> Furthermore, in ARMs case, the code explicitly states that these
> mappings are not used on SMP.  See the comment above the FLUSH_ALIAS_START
> definition in arch/arm/mm/mm.h

Yes, thankfully SMP on ARM requires non-aliasing data caches... and now
you've got me wondering whether that stuff is safe on preempt UP...

I'm thinking that both flush_icache_alias() and flush_pfn_alias() want
at least a preemption disabled around each so that we don't end up with
two threads being preempted here.

Thankfully, there's not many ARM CPUs with VIPT aliasing caches, which
is probably why no one has noticed.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.