Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756022AbbLGLra (ORCPT ); Mon, 7 Dec 2015 06:47:30 -0500 Received: from foss.arm.com ([217.140.101.70]:36276 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754797AbbLGLr2 (ORCPT ); Mon, 7 Dec 2015 06:47:28 -0500 Date: Mon, 7 Dec 2015 11:47:29 +0000 From: Will Deacon To: Oleg Nesterov Cc: John Blackwood , linux-kernel@vger.kernel.org, fweisbec@gmail.com Subject: Re: [PATCH] ARM64: Clear out any singlestep state on a ptrace detach operation Message-ID: <20151207114728.GC23430@arm.com> References: <5660A08B.6030204@ccur.com> <20151204100357.GA26172@arm.com> <20151205184840.GA6847@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151205184840.GA6847@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1919 Lines: 57 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 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. Oh, joy! > > --- 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. Fair enough. I don't think my patch changed any behaviour, but I can't test it for all the architectures I touched and this area is horribly fragile wrt userspace. I'll merge the original patch from John. Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/