[PATCH] arm64: Rework valid_user_regs
Mark Rutland
mark.rutland at arm.com
Wed Feb 10 08:01:27 PST 2016
On Wed, Feb 10, 2016 at 02:43:24PM +0000, Will Deacon wrote:
> On Wed, Feb 10, 2016 at 02:23:29PM +0000, Peter Maydell wrote:
> > On 10 February 2016 at 12:31, Mark Rutland <mark.rutland at arm.com> wrote:
> > > On Wed, Feb 10, 2016 at 11:58:53AM +0000, Will Deacon wrote:
> > >> 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?
Mark.
More information about the linux-arm-kernel
mailing list