----- On Jul 2, 2018, at 7:06 PM, Linus Torvalds torvalds@xxxxxxxxxxxxxxxxxxxx wrote: > On Mon, Jul 2, 2018 at 4:00 PM Mathieu Desnoyers > <mathieu.desnoyers@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
