Rethinking sigcontext's xfeatures slightly for PKRU's benefit?

[Andy Lutomirski]

Hi all-

I think that, for PKRU in particular, we want the default signal
handling behavior to be a bit unusual.

When a signal is delivered, I think we should save the entire xstate
including PKRU.  I see no reason to do anything other than that.

When a signal returns (sigreturn is called), though, I think we should
*not* restore PKRU.  To me, PKRU seems like a global per-thread state,
not something that signal handlers are likely to clobber and should
therefore have restored.  It's also unusual in that it doesn't fit
into the usual xstate feature model of being a bunch of registers that
are mostly caller-saved.

Does this make sense?  Should we do this?

We have _fpx_sw_bytes.xfeatures and _xstate._header.xfeatures.  They
appear to do more or less the same thing.  Could we say that, for
certain new features (e.g. PKRU), if they're not in
_fpx_sw_bytes.xfeatures, then sigreturn will preserve the old content
rather than copying it?  User code that wants to change it on
sigreturn would manually or the feature in to xfeatures, which would
cause the feature to go to its init state if it's not in
_header.xfeatures or to go into the saved state if it is in
_header.xfeatures?

Other means of signaling this could work, too.

It's not all that much code, I think.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/