[PATCH] arm64: Rework valid_user_regs

On Wed, Feb 10, 2016 at 04:04:21PM +0000, Will Deacon wrote:

On Wed, Feb 10, 2016 at 04:01:27PM +0000, Mark Rutland wrote:

quoted

On Wed, Feb 10, 2016 at 02:43:24PM +0000, Will Deacon wrote:

quoted

On Wed, Feb 10, 2016 at 02:23:29PM +0000, Peter Maydell wrote:

quoted

On 10 February 2016 at 12:31, Mark Rutland [off-list ref] wrote:

quoted

On Wed, Feb 10, 2016 at 11:58:53AM +0000, Will Deacon wrote:

quoted

I think we should err on the side of caution and nuke SS and IL for both
native and compat too, although that seems a odds with the PSR_s mask.
I wonder how relevant those PSR groups are in ARMv8...

Ok.

If you nuke SS does that have any side effects in the case
of (for instance) interactions between ptrace single step
and ptrace syscall tracing? (ie do we ever end up in a situation
where the ptracer can read a PSR for the debuggee which has
SS set? if so then it should be able to write back the PSR
it has just read without any bits being unset.)

I don't think so -- the signal dispatch logic "fast-forwards" the stepping
state machine so that we step into the signal handler, therefore the SS
bit should always be clear on entry afaict.

That handles entry, but what about exit?

Is there are a guarantee that we won't call user_enable_single_step() if
the return path is traced?

Why would that be a problem? I think I'm missing your point...

We would nuke the SS bit if the tracing happens after
user_enable_single_step, if the tracer fiddled with pstate at all. So
you wouldn't get the single stepping you expected.

Maybe I'm missing some reason this is prevented by construction.

Mark.