From: Oleg Nesterov <oleg@redhat.com>
To: Will Deacon <will.deacon@arm.com>
Cc: John Blackwood <john.blackwood@ccur.com>,
linux-kernel@vger.kernel.org, fweisbec@gmail.com
Subject: Re: [PATCH] ARM64: Clear out any singlestep state on a ptrace detach operation
Date: Sat, 5 Dec 2015 19:48:40 +0100 [thread overview]
Message-ID: <20151205184840.GA6847@redhat.com> (raw)
In-Reply-To: <20151204100357.GA26172@arm.com>
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 fab840fc2d542fabcab "ptrace: PTRACE_DETACH should do
flush_ptrace_hw_breakpoint(child)".
And the next "revert" commit, 35114fcbe0b9b0fa3f6653a2.
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -454,13 +454,20 @@ static bool __ptrace_detach(struct task_struct *tracer, struct task_struct *p)
> return dead;
> }
>
> +#ifndef arch_ptrace_detach
> +#define arch_ptrace_detach(child) do { } while (0)
> +#endif
> +
> static int ptrace_detach(struct task_struct *child, unsigned int data)
> {
> if (!valid_signal(data))
> return -EIO;
>
> - /* Architecture-specific hardware disable .. */
> - ptrace_disable(child);
> + arch_ptrace_detach(child);
> + user_disable_single_step(child);
> +#ifdef TIF_SYSCALL_EMU
> + clear_tsk_thread_flag(child, TIF_SYSCALL_EMU);
> +#endif
> clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
Well, personally I'd prefer to keep the arch-dependent ptrace_disable(), this
just looks safer to me. Although I agree that its name is bad and
arch_ptrace_detach() looks much better.
Oleg.
next prev parent reply other threads:[~2015-12-05 18:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-03 20:05 [PATCH] ARM64: Clear out any singlestep state on a ptrace detach operation John Blackwood
2015-12-04 10:03 ` Will Deacon
2015-12-05 18:48 ` Oleg Nesterov [this message]
2015-12-07 11:47 ` Will Deacon
-- strict thread matches above, loose matches on Subject: below --
2015-12-04 21:42 John Blackwood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151205184840.GA6847@redhat.com \
--to=oleg@redhat.com \
--cc=fweisbec@gmail.com \
--cc=john.blackwood@ccur.com \
--cc=linux-kernel@vger.kernel.org \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.