On 3/13/23 16:24, Jeff Xu wrote: > I have another case of test_ptrace_modifier_pkru failure. > This is happening in AMD 5000 CPU and 5.15.98 kernel. > The odd thing about this is: > if I run the whole set of protection_keys (20 cases), it will pass. > If I run the last case (by comment out the others), it will fail with > below error: > > has pkeys: 1 > startup pkey_reg: 0000000055555550 > assert() at protection_keys.c::1623 test_nr: 0 iteration: 1 > running abort_hooks()... > errno at assert: 0 > > And the same test on Intel CPU is passing. > > I wonder if this is known or someone has a repro ? > > Another question regarding PKRU, may or maynot related to this failure on AMD: > During the thread context switch, will PKRU be saved to the thread's > user space stack? Is this what XSAVE does (pre-5.14), and if we are > not using XSAVE after 5.15, what is used ? One Intel vs. AMD delta that I seem to recall is their init trackers. On Intel, the only "normal" way to get an XSAVE component back to being tracked as in its init state is with XRSTOR and the right incantations of XSTATE_BV and RFBM. On AMD, I think the init tracker is much more magic and aggressive. In addition to a careful XRSTOR, WRPKRU(0) _can_ put the PKRU state component back to being tracked as being in its init state. Also an XRSTOR with a PKRU value of 0 can do it. Basically, on AMD the register state matters for init tracking. On Intel, the actual register contents are not taken into account. It might be interesting to dump xgetbv(1) around the failures to see what's going on with the init tracker.
