On Jul 3, 2018, at 9:40 AM, Andi Kleen <andi@xxxxxxxxxxxxxx> wrote: >> >> So I think you're good... But yes, you raise an interresting point. > > So it sounds like architectures that don't have an instruction atomic u64 > *_user need to disable interrupts during the access, and somehow handle that > case when a page fault happens? I think all this discussion of “atomic” is a huge distraction. The properties we need are: - User code can change rseq_cs from one valid user pointer to another with a single instruction (or equivalent) such that we can’t end up in the kernel with the write only partially done as seen in that thread. - The kernel needs to be able to read the value consistently with the above requirement. I don’t think it’s possible to have a valid implementation of get_user() on any architecture that’s so weak that this doesn’t work. If user code writes rseq_cs from the wrong thread, I think the user code is buggy and we simply don’t care what happens. The kernel should be allowed to use an arbitrarily weak read with respect to other threads. -- 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
