lkml.org 
[lkml]   [2019]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: rcu_read_lock lost its compiler barrier
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

\
 
 \ /
  Last update: 2019-06-05 05:31    [W:0.093 / U:24.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site