----- On Jul 3, 2018, at 1:59 PM, Linus Torvalds torvalds@xxxxxxxxxxxxxxxxxxxx wrote: > On Tue, Jul 3, 2018 at 10:49 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: >> >> > I can simply document that loads/stores from/to all struct rseq fields >> > should be thread-local then ? >> >> I'm not sure that covers things sufficiently. You really want the >> userspace load/stores to be single instructions. > > Actually, I think we should try very hard to limit even that to _just_ > the rseq pointer itself. > > Everything else can be filled in ahead of time with non-atomic stores, > and then the last thing that happens - and the only thing that wants > that final "one last atomic write" is the rseq pointer write. > > No? Well a small nit here: the rseq->rseq_cs pointer store is performed at the _very beginning_ of the rseq critical section. We indeed want that store to be performed as a single instruction by user-space. What I think you have in mind as "one last atomic write" is the commit instruction at the end of the critical section, which does not touch any field in struct rseq. > > So I'd suggest that the only part we aim to have any "atomic" behavior > at all is for the individual fields in "struct rseq" itself. So the > cpu id and the base pointer and the flags. And even they are > thread-local, so the atomicity is not about the kernel, but about user > space needing to read and update them in word-sized chunks. > > End result: absolutely nothing is atomic for the kernel. Yes, +1. If everyone is OK with that I'll go and implement the changes within the coming day. 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
