[8u] RFR: nativeInstruction atomicity and correctness of patching
Edward Nevill
edward.nevill at gmail.com
Tue Apr 5 09:25:44 UTC 2016
Hi,
Was there a conclusion on this?
Are you happy with Anton's rev2 patch?
All the best,
Ed.
On Fri, 2016-04-01 at 10:41 +0000, Anton Kozlov wrote:
> Hi, Andrew,
>
> On Thu, 2016-03-31 at 09:49 +0100, Andrew Haley wrote:
> > On 30/03/16 20:53, Anton Kozlov wrote:
> >
> > > On Wed, 2016-03-30 at 16:25 +0100, Andrew Haley wrote:
> > > > On 03/30/2016 04:15 PM, Anton Kozlov wrote:
> > > > > ICache::invalidate_word used here not to provide coherency
> > > > > between
> > > > > Icache and Dcache, but to maintain in-order visibillity of code
> > > > > modification.
> > > >
> > > > What exactly are you trying to synchronize?
> >
> > > ICache::invalidate ensures that all CPUs see modifications of code.
> > > Data modification in trampoline should be visible in the same way,
> > > same time as code modification would. For this ICache::invalidate
> > > used, as it by implementation should synchornize dcaches among
> > > CPUs.
> >
> > I don't think so. In order for this to work, the *reader* would have
> > to execute some kind of fence too. I don't think that's possible
> > without an inter-processor interrupt across all cores, and I think
> > that __clear_cache doesn't do that. I certainly hope not.
> >
> > > > > This is achieved by implementation of ICache::invalidate_word,
> > > > > which is just call to __clear_cache syscall wrapper.
> > > >
> > > > I don't think there's any point. It's not instructions but data,
> > > > so
> > > > ICache::invalidate_word is inappropriate.
> > >
> > > Agree, ICache is bad name for that. How about direct __clear_cache
> > > call?
> >
> > > Also, I will try to study implementation of __clear_cache to know,
> > > how exactly it's done.
> >
> > I think you will find that it does not do what you think it does.
> > I'm
> > looking at linux/arch/arm/include/asm/cacheflush.h and I can't see
> > anything like that. All I see is that do_cache_op calls
> > __flush_cache_user_range, and all that does is ensure that the I and
> > D
> > caches are coherent.
More information about the aarch32-port-dev
mailing list