[PATCH V2] arm64: add DSB after icache flush in __flush_icache_all()

Will Deacon will.deacon at arm.com
Mon Feb 3 06:17:54 EST 2014


Hi Nico, Russell,

Thanks for the replies.

On Fri, Jan 31, 2014 at 10:48:50AM +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 31, 2014 at 12:16:48AM +0000, Will Deacon wrote:
> > On Thu, Jan 30, 2014 at 09:42:29PM +0000, Nicolas Pitre wrote:
> > > I don't think they would be reordered at all with the 
> > > volatile qualifiers.
> > 
> > Whilst that may be the case in current compilers (i.e. I've not actually
> > seen the above sequence get re-ordered), the GCC documentation states that:
> > 
> >   Similarly, you can't expect a sequence of volatile asm instructions to remain
> >   perfectly consecutive. If you want consecutive output, use a single asm. Also,
> >   GCC performs some optimizations across a volatile asm instruction; GCC does not
> >   `forget everything' when it encounters a volatile asm instruction the way some
> >   other compilers do.
> > 
> > so I really think that the "memory" clobbers are needed to ensure strict
> > ordering. This matches my understanding from discussions with the compiler
> > engineers at ARM.
> 
> What it means is that the compiler may introduce additional instructions
> between your consecutive asm() statements.  So there's no guarantee that
> the ISB will immediately follow the MSR instruction - there may be other
> instructions which the compiler may decide to schedule between the two.
> 
> For example, instructions to load the address of the variable(s) may be
> inserted between the assembly specified in the asm() statements which
> may involve loading from a literal pool.

That matches what Nicolas said and, to be honest, makes a lot of sense. I'm
just slightly concerned that it doesn't match the explanation I received
from some compiler guys, but I can chase that down separately.

Vinayak: sorry for leading you down the garden path on this. Please can you
stick with your original patch, but adding something equivalent for
arch/arm?

Cheers,

Will



More information about the linux-arm-kernel mailing list