lkml.org 
[lkml]   [2018]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH for 4.18] rseq: use __u64 for rseq_cs fields, validate user inputs
    ----- On Jul 2, 2018, at 8:19 PM, Chris Lameter cl@linux.com wrote:

    > On Mon, 2 Jul 2018, Mathieu Desnoyers wrote:
    >
    >> Are there any kind of guarantees that a __u64 update on a 32-bit architecture
    >> won't be torn into something daft like byte-per-byte stores when performed
    >> from C code ?
    >>
    >> I don't worry whether the upper bits get updated or how, but I really care
    >> about not having store tearing of the low bits update.
    >
    > Platforms with 32 bit word size only guarantee atomicity of a 32 bit
    > write or RMV instruction.
    >
    > Special instructions may exist on a platform to perform 64 bit atomic
    > updates. We use cmpxchg64 f.e. on Intel 32 bit platforms to guarantee
    > atomicity8.
    >
    > So use the macros that we have to guarantee 64 bit ops and you should be
    > fine. See linux/arch/x86/include/asm/atomic64_32.h

    We are talking about user-space here. What we need is a single instruction
    atomic store, similar to what WRITE_ONCE() does in the kernel. The discussion
    is about whether doing the user-space equivalent of a WRITE_ONCE() to a u64
    on a 32-bit architecture should be considered to provide single-copy atomicity
    on the low 32 bits.

    Thanks,

    Mathieu


    --
    Mathieu Desnoyers
    EfficiOS Inc.
    http://www.efficios.com

    \
     
     \ /
      Last update: 2018-07-03 02:24    [W:3.560 / U:1.344 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site