Re: interesting commit about llvm introducing barrier_data()

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Tue, Feb 23, 2016 at 02:58:37PM +0000, Mathieu Desnoyers wrote:
> ----- On Feb 23, 2016, at 9:46 AM, Stephan Mueller smueller@chronox.de wrote:
> 
> > Am Dienstag, 23. Februar 2016, 14:32:43 schrieb Mathieu Desnoyers:
> > 
> > Hi Mathieu,
> > 
> >> ----- On Feb 23, 2016, at 9:23 AM, Paul E. McKenney
> > paulmck@linux.vnet.ibm.com wrote:
> >> > On Tue, Feb 23, 2016 at 02:02:26PM +0000, Mathieu Desnoyers wrote:
> >> >> commit 7829fb09a2b4268b30dd9bc782fa5ebee278b137
> >> >> Author: Daniel Borkmann <daniel@iogearbox.net>
> >> >> Date:   Thu Apr 30 04:13:52 2015 +0200
> >> >> 
> >> >>     lib: make memzero_explicit more robust against dead store elimination
> >> >> 
> >> >> ^ interesting commit. Any idea on the impact of this on kernel RCU
> >> >> implementation and liburcu cmm_barrier() ?
> >> > 
> >> > First I knew of it!  But I bet that more like this are needed.  ;-)
> >> 
> >> I recommend you check my IRC discussion with peterz on the matter of
> >> this new "barrier_data()".
> >> 
> > The key idea of the memzero_explicit is about forcing the compiler to do a
> > memset.
> > 
> > See the trivial test attached.
> 
> My question is mainly about documentation of the new "barrier_data()"
> added to include/linux/compiler-gcc.h. Its comment does not clearly
> state where it should be used, and where it should not be needed.
> 
> If it is useful for clearing memory for security purposes, it
> should be stated in the comment above the macro, and in the
> memory-barriers.txt Documentation file.
> 
> If it is useful for securely clearing local variables in
> registers and on stack, it should be documented. Or if
> variables sitting on stack are not a target here, it should
> be documented too.
> 
> If there is any way this could have impacts on DMA reads/writes
> (typically only global and allocated variables), it should be
> documented.
> 
> If beyond the "clearing memory for security" use-case, this
> new barrier is needed rather than barrier() for code correctness,
> it should also be documented.

Looks like this is an issue only for code that doesn't use WRITE_ONCE()
or better for writes to shared variables.  Of which there does appear
to be a great deal in the kernel, to be sure...

							Thanx, Paul