Messages in this thread | | | Date | Tue, 3 Jul 2018 10:29:55 +0200 | From | Heiko Carstens <> | Subject | Re: [RFC PATCH for 4.18] rseq: use __u64 for rseq_cs fields, validate user inputs |
| |
On Tue, Jul 03, 2018 at 10:14:49AM +0200, Peter Zijlstra wrote: > On Mon, Jul 02, 2018 at 10:30:09PM -0400, Mathieu Desnoyers wrote: > > > Use "get_user()". It works for 64-bit objects too, and it will be > > > atomic in the 32-bit sub-parts on a 32-bit architecture. > > > > Is it really ? Last time we had this discussion, not all architectures > > guaranteed that reading a 64-bit integer would happen in two atomic > > 32-bit sub-parts. This was the main motivation for the LINUX_FIELD_u32_u64() > > macro as it stands today (rather than using a union). > > Just state, as a requirement for supporting rseq, that the arch > {get,put}_user(u64) on 32bit targets must be exactly 2 u32 loads/stores. > > We're piece-wise enabling rseq across architectures anyway, and when the > relevant maintains do this, they can have a look at their > {get,put}_user() implementations and fix them. > > If you rely on get_user(u64) working, that means microblaze is already > broken, but I suppose it already was, since their rseq enablement patch > is extremely dodgy. Michal?
s390 uses the mvcos instruction to implement get_user(). That instruction is not defined to be atomic, but may copy bytes piecemeal.. I had the impression that the rseq fields are supposed to be updated within the context of a single thread (user + kernel space).
However if another user space thread is allowed to do this as well, then the get_user() approach won't fly on s390.
That leaves the question: does it even make sense for a thread to update the rseq structure of a different thread?
| |