----- On Jul 2, 2018, at 7:06 PM, Linus Torvalds torva...@linux-foundation.org wrote:
> On Mon, Jul 2, 2018 at 4:00 PM Mathieu Desnoyers > <mathieu.desnoy...@efficios.com> wrote: >> >> Unfortunately, that rseq->rseq_cs field needs to be updated by user-space >> with single-copy atomicity. Therefore, we want 32-bit user-space to >> initialize >> the padding with 0, and only update the low bits with single-copy atomicity. > > Well... It's actually still single-copy atomicity as a 64-bit value. > > Why? Because it doesn't matter how you write the upper bits. You'll be > writing the same value to them (zero) anyway. > > So who cares if the write ends up being two instructions, because the > write to the upper bits doesn't actually *do* anything. > > Hmm? 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. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
