On Wed, Jun 05, 2019 at 10:21:17AM +0800, Herbert Xu wrote:
> On Tue, Jun 04, 2019 at 02:14:49PM -0700, Paul E. McKenney wrote:
> >
> > Yeah, I know, even with the "volatile" keyword, it is not entirely clear
> > how much reordering the compiler is allowed to do. I was relying on
> > https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html, which says:
>
> The volatile keyword doesn't give any guarantees of this kind.
> The key to ensuring ordering between unrelated variable/register
> reads/writes is the memory clobber:
>
> 6.47.2.6 Clobbers and Scratch Registers
>
> ...
>
> "memory" The "memory" clobber tells the compiler that the assembly
> code performs memory reads or writes to items other than those
> listed in the input and output operands (for example, accessing
> the memory pointed to by one of the input parameters). To ensure
> memory contains correct values, GCC may need to flush specific
> register values to memory before executing the asm. Further,
> the compiler does not assume that any values read from memory
> before an asm remain unchanged after that asm; it reloads them as
> needed. Using the "memory" clobber effectively forms a read/write
> memory barrier for the compiler.
>
> Note that this clobber does not prevent the processor from
> doing speculative reads past the asm statement. To prevent that,
> you need processor-specific fence instructions.
>
> IOW you need a barrier().
Understood. Does the patch I sent out a few hours ago cover it? Or is
something else needed?
Other than updates to the RCU requirements documentation, which is
forthcoming.
Thanx, Paul
