On 2019-01-21 12:21:17 [+0100], Oleg Nesterov wrote: > > This is part of our ABI for *sure*. Inspecting that state is how > > userspace makes sense of MPX or protection keys faults. We even use > > this in selftests/. > > Yes. > > And in any case I do not understand the idea to use the second in-kernel struct fpu. > A signal handler can be interrupted by another signal, this will need to save/restore > the FPU state again. So I assumed that while SIGUSR1 is handled SIGUSR2 will wait until the current signal is handled. So no interruption. But then SIGSEGV is probably the exception which will interrupt SIGUSR1. So we would need a third one… The idea was to save the FPU state in-kernel so we don't have to revalidate everything because userspace had access to it and could do things. Some things are complicated and not documented why they are the way they are. For instance on 64bit (based on the code) the signal handler can remove SSE from the state-mask and the kernel loads the "default-empty" SSE registers and the enabled states from user. This isn't done on 32bit. Also: we save with XSAVE and allocate the buffer on stack. But if we can't find the FP_XSTATE_MAGIC* or the buffer is not properly aligned then we fallback to FXSR and assume that we have a FXSR buffer in front of us. > Oleg. Sebastian
