The 10/11/2021 21:10, Mark Brown wrote: > On Mon, Oct 11, 2021 at 03:19:37PM +0100, Szabolcs Nagy wrote: > > > if fork resets tpidr2 then returning to a stack frame > > that set tpidr2 could cause clobbered za state. > > (userspace can fix this up, but if we want this case > > to work then it's better to fix it on the kernel side) > > OK, that makes sense. I've changed the code and the kselftest so that > TPIDR2 is preserved on thread creation. does thread creation have to work the same way as fork? (in a pthread_create child we want tpidr2 to be 0, since it represents thread specific data. in a fork child we want to preserve tpidr2 to mirror the state of the parent as much as possible) for sme pcs to work, the libc has to be updated anyway, so we can change the clone child to set tpidr2. however that's not atomic wrt thread creation. i don't think we aim to support async-signal-safe za usage in the pcs so this is not a problem, but if the kernel did the work then the situation would be clearer in userspace. i'm not sure when to do tpidr2=0 exactly, but something like CLONE_SETTLS is set or child runs on a new stack would work for me. if that's too ugly then preserving tpidr2 in the child is fine.
