On Sat, Dec 05, 2015 at 07:48:40PM +0100, Oleg Nesterov wrote:
> On 12/04, Will Deacon wrote:
> >
> > I hacked up a quick patch below (not even compile-tested), but I'm not
> > sure what to do about hardware {break,watch}points. Some architectures
> > explicitly clear those on detach, whereas other
On 12/04, Will Deacon wrote:
>
> I hacked up a quick patch below (not even compile-tested), but I'm not
> sure what to do about hardware {break,watch}points. Some architectures
> explicitly clear those on detach, whereas others appear to leave them
> alone. Thoughts?
Heh ;)
Please see fab840fc2d5
Subject: Re: [PATCH] ARM64: Clear out any singlestep state on a ptrace detach
operation
From: Will Deacon
Date: 12/04/2015 04:03 AM
To: "Blackwood, John"
CC: "linux-kernel@vger.kernel.org" , "o...@redhat.com"
, "fweis...@gmail.com"
On Thu, Dec 03,
On Thu, Dec 03, 2015 at 02:05:31PM -0600, John Blackwood wrote:
> Hello Will,
Hi John,
Thanks for the patch.
> I have a patch for a ptrace(2) issue that we encountered on arm64 kernels.
> If a debugger singlesteps a ptraced task, and then does a ptrace(2)
> PTRACE_DETACH command, the task will n
Hello Will,
I have a patch for a ptrace(2) issue that we encountered on arm64 kernels.
If a debugger singlesteps a ptraced task, and then does a ptrace(2)
PTRACE_DETACH command, the task will not resume successfully. It seems
that clearing out the singlestep state, as something like a ptrace(2)
P
5 matches
Mail list logo