On 05/02/2018 03:22 PM, Andy Lutomirski wrote: > That library wants other threads, signal handlers, and, in general, the > whole rest of the process to be restricted, and that library doesn't want > race conditions. The problem here is that, to get this right, we either > need the PKRU modifications to be syscalls or to take locks, and the lock > approach is going to be fairly gross. I totally get the idea that a RDPKRU/WRPKRU is non-atomic and that it can't be mixed with asynchronous WRPKRU's in that thread. But, where do those come from in this scenario? I'm not getting the secondary mechanism is that *makes* them unsafe. -- 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
